Requirements
=============
This isn't a requirements spec in the strictest sense of the word. For
now, it is a mix of philosopical design statements and a few actual
requirements. This document will evolve into two documents, one for
design philosophy and one with functional requirements.

Sending data
-------------

- Having to construct strings and then sending them off is tedious
- Having to figure out which output format the requester wants takes a
  lot of code. This code is duplicated for each resource. How do we
  avoid this?
- When writing handler we will probably use the other HTTP statues as
  often as 200 OK. Should the framework really be so strongly biased
  towards returning OK.

Parsing data and headers
------------------------
- The "if soup" found at the top of most request handlers is just
  horrible. Frameworks should provide some way to build reuseable
  validation components without restricting programmer freedom or
  introducing "magic" Parsing parameters should be declarative


Configurability and Extensibility
----------------------------------
- Many web libraries and frameworks take over the native environment
  and force the programmer to work inside the boundaries of the
  framework. We should let the programmer use a much or as little of
  our library as he or she wants to. This means not launching the
  program using a special or taking over the environment.
  
- We should allow the user to use any means of configuration that he
  or she wants to by providing a simple way to plugin in their values
  programmatically.

- The programmer should be able to store arbitrary values in our
  configuration system and reuse this for his or her code.

- The programmer should be able to override request handling logic,
  even down to the socket level.

- It should be possible for the programmer to add some kind of
  middleware, prior to or after the request has been processed with by
  the framework.