-	configuration
	-	get a yaml engine into the bootstrap process and move all configs to it
-	make all classes in all modules DYNAMICALLY LOADED!!!
-	future modules
	-	mail
		-	Message
		-	SmartMessage
	-	translate
	-	xml
		-	works with both php4 and php5
	-	sequence
	-	storage
	-	fpdf
	-	rospdf
	-	spell
	-	cli
	-	server
		-	smtp
		-	http
		-	session
		-	sql???
	-	some sort of guicontrols like thing
	-	graphic
		-	contexts for gd, imagemagic, fpdf, rospdf, flash, svg, etc.
	-	graph
	-	auth???
	-	a package/module/bundle manager (like unto gems)
		-	maybe use the pear module manager
		-	or rpm
		-	or apt-get/deb
		-	roll your own?
	-	wiki
		-	have code for translating complicated wiki style formatting into:
			-	html
			-	graphic/xml
	-	filter
		-	look at the GetPost* functions in pehppy and also see what they have done with the php filtering extension
	-	ajax
		-	dojo?
	-	rad/"scaffolding"
		-	edit actual files or just produce code for you to copy and paste
		-	cli first - open in textmate?
	-	permissions
	-	caching
		-	template caching
		-	url (virtual path) caching
		-	data / object cache
		-	query caching
		-	app variables stored in shared memory
		-	file (or memory or db) based caching of compiles resources
	-	logging
		-	performance logging
			-	by page
			-	with custom profile segments
		-	error logging
		-	assert / condition logging
		-	audit logging
	-	crawl
		-	a way to crawl sites with a script and curl
		-	can be used for testing or making an api to a website you don't control
-	work on existing modules
	-	zone
		-	automatically display templates?
		-	automatically determine file output type?
-	skeleton
	-	have more than one skeleton
	-	autogenerate it
		-	change the way zone params are handled
			-	no more "function getParamNames..."
			-	instead use $this->addZoneParam($paramName, $paramType, $extra)
				-	$paramType is one of {int, identifier, regex, ...}
					-	maybe default to identifier
					-	also maybe put a limit on the length (like maybe 20 chars or so)
		-	change the way page params are handled
			-	allow you to have a paramsxxx function that corresponds to the pagexxx and postxxx functions
				-	it will allow you to assign names, validation types and length limits as with zone params above
				-	they will be optional but will default to using numric indicies for names as it does now, with type identifier and the same default length limit as the zone params above
-	apps to port
	-	translate
	-	directory
-	server module
	-	http server
	-	zoop app server
	-	db server
	-	dns server
	-	mail server
-	differences
	-	more advanced security system
	-	controller
	-	graphic system
	-	translation system
	-	session system
	-	xml handling???
	-	workflows
	-	storage system
	-	spell checker
	-	routing mechanism
	-		we don't have the overhead of complex pattern based routes : but we don't have the flexilibilty either : does it matter in practical terms
	-	post functions
		-	rails seems to separate out different actions in the controller whereas we make a switch statement in the post function
		-	how do they handle the navigation???
		-	do they prevent the dreaded "do you want to post this data again" message?
	-	navigation, sequences, etc
	-	smarty / mizithra tags escaped by default, no h() required
	-	find often equates to putting sql in your code, we try to do that less
	-	also the late static binding issue is less of a problem when we wrap everything
	-	post functions vs the alternatives
		-	button_to
			-	you have to include any data that it needs, often you are going to just want data from the form
			-	it creates a div???, why does it do that.  then you need to make special style, mapped to every button to prevent it from doing that
	-	error handling
		-	we automatically never now anything in production (although it looks like it does this too)
-	design goal
	-	keep global configurations global and local configurations local (and close to what they affect)
		-	for example zone params go in the zone not in some big master config file
-	security
	-	make sure you always do all validation
-	utils
	-	make them all static members of a class, also probably just move utils.php into the app module
-	gpl
	-	have a way with integrating with GPL software without exposing yourself to it's licencing conditions
		-	make these separate projects that 
		-	create a chart server with open flash charts (http://teethgrinder.co.uk/open-flash-chart/tutorial.php) that 
			adheres to some zoop specific API
			-	actually only open flash charts one is GPL, version 2 is LGPL, the server might be useful on it's own
				-	though it would abstract chart creation from the application and make it resuable
		-	same for flowplayer (http://flowplayer.org/)
		-	and pChart (http://pchart.sourceforge.net/)
-	media
	-	integrate with open source flash video viewer flowplayer
	-	make them all static members of a class, also probably just move utils.php into the app module