	*	Handle exceptions better.  Rather than just dumping unhandled exceptions
		to the output stream, treat them intelligently.  If the request came from
		a predefined set of "internal" addresses, then show a nicely formatted
		version of the exception, complete with code context lines.  If the
		request same from any other address, then display a configurable
		error page so that the user receives something friendly rather than
		exception backtrace gunk.
	*	Testing.  Need to make tests for Iowa itself and need to add more support
		for creating unit tests of one's application, too.
	*	Short term item -- Iowa::Client really needs some exception handling
		rolled into it.
	*	Add support for SSL encryption of the communications stream
		between the client and the servlet when using a TCPSocket.  The
		idea being that this prevents snooping of potentially sensitive data
		if the servlet is across an open network from the client.
	*	Use something other than Marshal to send Iowa::Request from the
		webserver to the Iowa process.  Maybe Iowa::Request should simply
		serialize the DATA into some simple format?  That way I could have
		a non mod_ruby driven solution.  mod_iowa.c would live again. YAML?
		YAML is too slow.  Another advantage of going to a protocol like this,
		though, is that support could then be built for streaming the Iowa
		generated content back to the browser as it is generated, rather than
		buffering it all and returning it all in one chunk.  For content that
		takes a while to generate, this would have the advantage of giving
		one something to look at while it is built.
	*	Still more test suites.
	*	Devise a solution to allow more than one server to process requests,
		to allow for better scalability.  The trick here is how to make the
		state information shareable between n different servers in an
		efficient way?  Either that, or there needs to be session affinity at the
		web server level so that the Iowa process that first handles a request
		from a given user handles subsequent requests.
	*	Add support for emitting HTML?  i.e. if there is a section within
		a template where the content has to be determined completely by
		code such that one can't actually template it, support for
		emitting that HTML should be provided?
	*	Support some more syntactic niceties in the template, such at
		creating implicit bindings via a syntax such as:
		
		<repeat list="(1..20)" item="n">
			@n<br/>
		</repeat>
		
		This would create a list of the numbers from 1 to 20, one per line.
		I definitely need to do more exploration here. 
	*	There are times when a client really does not want to see bizarre
		urls on a site, even in the middle of an application.  Produce an
		easily pluggable solution so that the session ID and page count
		can get stuffed into a cookie and queried from a cookie instead
		of being passed in the URL.  This would allow all traffic to
		http://frotz.bitzma.com/coolapp to go to that one, clean URL, with
		most of the ugly little unique identifiers being hidden from the eyes
		of picky customers.
	*	Go through the code with a fine toothed comb and try to improve
		performance.  Performance of execution is generally pretty good,
		though I feel confident there are places where it can be improved.
		Performance when parsing a template, however, is horrible.  There
		has to be some way to improve the parsing speed or to cache the
		parsed template in some sort of persistent store so that, at least
		in the cases where there have been no changes to the code or to
		the layout, a restart is fast.
	*	Improve the parsing of custom tags so that kludges like:

		<PageHeader oid="pageHeader"/>

		are not needed.  Really, we shouldn't have to pass an oid
		with an attribute if we aren't actually doing anything with it.

		<PageHeader/>

		would be great.