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

[Greg Ward]

On 29 October 2003, Ian Bicking said:
> The difficulty of writing, say, request.response.write(something) vs. 
> handler.write(something) doesn't seem like a big deal to me.

FWIW, this is how Quixote works.  We started out with completely
separate HTTPRequest and HTTPResponse objects (borrowed from Zope, and
drastically stripped down).  Then somewhere along the line, someone
(Neil S. I think) noted, like Greg S., that you can't have a response
without a request, and vice-versa.  So now the HTTPResponse object is a
accessible as request.response.

It's convenient and simple, and I agree that the request and response
are indeed distinct concepts.  But Greg S.'s "handler" idea has an
appeal too.  One thing that bugs me about Quixote's request.response is
that the request is "special" because it's what's passed around, and the
response is subordinate to it.  That's wrong; although the request comes
first chronologically, the two are equally important in a typical web
app.  So right now I think I'm 51% in favour of a single object.

But I'm not sure if "handler" is the right name though: in English, I
would call it an "HTTP request/response cycle", but that's a bit of a
mouthful for a classname.  (Except in Java, but LetsNotGoThere.)  Maybe
HTTPTransaction -- tack on the "HTTP" and it's pretty clear we're not
talking about databases.

        Greg
-- 
Greg Ward <gward at python.net>                         http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!