[Web-SIG] [server-side] request/response objects

[David Fraser]

Greg Stein wrote:

>In the most recent incarnation of a webapp of mine (subwiki), I almost
>went with a request/response object paradigm and even started a bit of
>refactoring along those lines. However, I ended up throwing out that
>dual-object concept.
>
>When you stop and think about it: *every* request object will have a
>matching response object. Why have two objects if they come in pairs? You
>will never see one without the other, and they are intrinsically tied to
>each other. So why separate them?
>
>I set up the subwiki core to instantiate a "handler" each time a request
>comes in. That Handler instance provides access to the request info, and
>is the conduit for generating the response. The app dispatches to the
>appropriate command function, passing the handler.
>
>The Handler is actually set up as a base class, with two subclasses so
>far: cgi, and cmdline. This lets me do some testing from the command line,
>along with the standard cgi model of access. At some point, I'll implement
>a mod_python subclass to do the request/response handling.
>
>(as a side note, I'll also point out that Apache operates this way, too;
> everything is based around the request_rec structure; it holds all the
> input data, output headers, the input and output filter chains, etc)
>
>
>In any kind of server-side framework design, I would give a big +1 to
>keeping it simple with a single "handler" type of object rather than a
>dual-object design.
>
>Cheers,
>-g
>
+1 from me too.
We should also think about things that may/may not be supported by the 
API, such as filters in Apache 2
These seem to me to be a very Pythonic concept that could easily be 
layered on top of any underlying API
If the request-response object is well designed, filters could fit 
snugly on top of it.

David