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

[David Fraser]

Greg Stein wrote:

>On Mon, Oct 27, 2003 at 09:47:12AM +0200, David Fraser wrote:
>  
>
>>Gregory (Grisha) Trubetskoy wrote:
>>
>>    
>>
>>>For what it's worth, I never liked the request/response separation either.
>>>I like a single object from which you can read() and to which you can
>>>write(), just like a file. Imagine if for file IO you had to have an
>>>object to read and another one to write?
>>>      
>>>
>
>Woah. Nice analogy. Thanks.
>
>  
>
>>>(I would agree that perhaps "request" is a misnomer, but I can't think of
>>>anything better)
>>>      
>>>
>>Connection? I think someone suggested "Transaction" for this, but it 
>>sounds out of place here...
>>    
>>
>
>Nope. A number of request/response pairs occur on a given connection. The
>two are rather independent concepts. That was one of the basic tenets to
>my redesign of httplib. The old HTTP(S) classes are individual requests,
>which sucks for performance. With the new HTTP(S)Connection, you can open
>a connection, and then issue multiple requests over it.
>  
>
OK. Now in this case, you clearly can't handle more than one 
request/response on a single connection at a time.
So would it be feasible (I'm not suggesting it's neccessarily a good 
idea) to use a Connection object, which changes state to reflect the 
request-responses?
Or should a Connection object create separate request-response objects 
for each event?
The reason I'm asking is, surely the response write method will simply 
flow through to the underlying Connection.
Though this may be an implementation detail, it may say something about 
how the API should work.

>The name for the thing can be one of two things, I believe, depending on
>where you focus:
>
>  - focus on the transaction itself
>  - focus on the thing handling the transaction
>
>Per my original note here, SubWiki tends towards the latter. Each incoming
>request instantiates a Handler which deals with both reading/writing at a
>basic level (although there are still external entities which treat the
>Handler instance like in the first focus type).
>
>"Transaction" does sound out of place since that has connotations of a
>database transaction. I don't have any better suggestions (as I've never
>had to ponder a name for it since I didn't choose that focus :-)
>
>In the first model, the transaction is a passive entity, dealt with by
>some other code which does the processing. In the second model, the
>transaction and processing are bundled into the same object -- this is
>where you'd instantiate some thing and call a "run" method on it, which
>Does The Right Thing. I tend to disfavor that model because the conflation
>of data and request processing gets to be very cumbersome and tangled.
>Instantiating objects, custom to the request (type), to do the processing
>is all well and fine, but pass along a (relatively) passive data object to
>it (IMO).
>
>Cheers,
>-g
>
>  
>
Looking at it from an API point of view, the difference is between 
creating a request-response object structure which any of the various 
implementors can handle in their code, and creating a handler object 
structure which the various implementors have to conform to, either by 
changing the existing implementation or by writing wrappers around their 
existing code. I think the request-response object idea is clearly 
simpler from this point of view...

David