[Web-SIG] [server-side] request/response objects
Brian Olsen - Lists
mailinglists at qinternet.com
Wed Oct 29 11:17:39 EST 2003
On Wednesday, October 29, 2003, at 02:32 AM, Ian Bicking wrote:
> On Friday, October 24, 2003, at 03:20 PM, 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?
>
> The biggest justification for me is: because that's what everyone
> does. SkunkWeb doesn't separate them, but I can't think of any others
> in Python. The request/response distinction is ubiquitous throughout
> web programming. I guess it's natural to people. But it doesn't even
> matter why: it is the way it is.
> Another justification is that the request is essentially static. It
> is created and complete, then it is processed. When the request is
> complete, the response has just barely begun existence. The request
> object could very well be immutable at this point. (Unfortunately
> that probably would make compatibility with previous code too
> difficult, but that's an aside) You can very reasonably pass around
> the request with the expectation that the response will not be
> touched, or even vice versa (though that is less common -- which is a
> bit backwards if you follow a convention that the response belongs to
> the request).
> The request and response aren't particularly interwoven either.
> Request cookies have nothing to do with response cookies (and any
> attempt to combine their semantics would be futile). Request
> variables follow arcane paths through all kinds of representations
> when you trace them back to their source.
>
> And then there's simply the naming issue: request and response are
> pretty clear names. Everyone knows what they are. Everyone can guess
> at their interface, and certainly can read their interface. There's
> no compelling alternative name for the combined object -- "handler"
> implies almost nothing, "transaction" implies the incorrect thing,
> "connection" implies a low-level interface...
>
> The difficulty of writing, say, request.response.write(something) vs.
> handler.write(something) doesn't seem like a big deal to me.
Reading this thread, it sounds more like an aesthetic choice than
anything. I like single objects, but this is also aesthetic. (Maybe you
can call the single object HTTPConnection? That's what it is, no?)
But if I am going to fight something for no particular reason, it will
be against dual-objects, just to be against the dual-object status quo.
:-)
Fight for the single-object!!
Beian
More information about the Web-SIG
mailing list