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

[Greg Stein]

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.

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

-- 
Greg Stein, http://www.lyra.org/