[Web-SIG] [server-side] request/response objects
davidf at sjsoft.com
Mon Oct 27 02:49:00 EST 2003
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
>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
+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.
More information about the Web-SIG