The following are some ideas of a web framework I've wanted to build for a time
but haven't yet because I'm focusing on other things.

NOTE: these are mostly random thoughts and I probably need to spike something
out before they become coherent.

- Is not based on Rack

- Requests and responses are not buffered, and are instead treated as streams
- Uses at least one thread per core, each with an event loop listening to
  a socket and handling requests independently.
- Look at cool.io for handling IO and http_parser.rb for parsing HTTP.

- Each request would be handled by a state machine that changes state and starts
  routing the request *as* the request is being streamed in.
  - When the request line is read in, specifically the method and URL, the
    state machine will attempt to find a matching resource immediately. If it
    cannot, it will return a 404. If it can, then it will ask the resource
    what headers it needs (which should be declared in the resource) and
    keep reading the input until they are seen, initializing the resource
    at that point.
- Refer to the following flowchart when writing the request handler
  for the state machine: http://webmachine.basho.com/diagram.html

- All HTML partial/fragments are included using ESI. Each fragment is generated
  by a separate handler, and has an independent caching policy.
- By default everything is cachable forerver. Handlers can configure if
  a resource cannot be cached, or if it can only be cached for a limited
  time.
- All responses include an ETag/Last-Modified header generated using the
  state of the resource object.
- Request headers are unknown to the event handlers unless explicitly
  declared. When declared they will be added to the response Vary header,
  because it will be assumed they were used in the decision making process.

- Instead of controllers there will be resource objects. Their constructor
  will load the object and setup the state.
  - GET/HEAD requests will not execute a handler, since they just return the
    state of the object which was setup in the constructor.
  - PUT/POST/DELETE handlers will be able to modify the state of the object.
  - Similar to this:
    http://roberthahn.ca/articles/2007/08/17/the-ideal-rest-framework/

- Each resource will be able to specify what methods are allowed given the
  request context.
  - OPTIONS handlers will use this to set the Allow response header.

- Conditional request handling should be baked in. Before a handler is
  invoked the system should check the appropriate If-* header and return
  a 304 or 412 depending on the method.

- I want to decouple input processing, the event handler, and output
  generation. The event handler will have no knowledge of input/output
  formats, etc. It will just be concerned about carrying out the state
  change (in the event of put/post/delete, etc).
  - Input processing is handled by an object that works with streaming
    input. The proper handler will be negotiated based on the request
    content-type.
  - Output processing can be done by something similar to a presenter.
    It will be able to use content negotiation to choose the best
    representation for the resource.

- Resource methods will be able to set state for the representation,
  add general/response headers, and return the HTTP status, but
  otherwise cannot affect the entity headers or representation directly.

- The general/response headers should be written to the socket as soon
  as possible, ideally as soon as the resource method is finished. Then
  the entity headers can be written after negotiation.