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

[Brian Olsen - Lists]

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