tseaver at palladion.com
Mon Oct 22 19:29:17 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Guido van Rossum wrote:
> Cool. I already heard in the grapevibe about webob.py.
>> Anyway, I'd be interested in feedback. We've talked a little about a
>> shared request object -- only a little, and I don't know if it is really
>> a realistic goal to even try. But I think this request object is a
>> considerably higher quality than any other request objects out there.
>> The response object provides a nice symmetry, as well as facilitating
>> testing. And it's also a very nice response object.
> I may be totally behind the times here, but I've always found it odd
> to have separate request and response objects -- the functionalities
> or APIs don't really overlap, so why not have a single object? I'm
> really asking to be educated; I severely hope there's a better reason
> than "Java did it this way". :-)
HTTP has both headers and payload supplied by the client and returned by
the server: not mixing them up is probably the driving reason for
keeping separate objects. Of course, you could make one object with
'request' and 'response' attributes, but that wouldn't really be a
>> They are both fairly reasonable to subclass, if there are minor naming
>> issues (if there's really missing features, I'd like to add them
>> directly -- though for the response object in particular it's likely
>> you'll want to subclass to give application defaults, like a default
>> content type).
>> It's based strictly on WSGI, with the request object an almost-stateless
>> wrapper around a WSGI environment, and the response object a WSGI
>> application that contains mutable status/headers/app_iter.
>> Almost all the defined HTTP headers are available as attributes on the
>> request and/or response. I try to parse these in as sensible a way as
>> possible, e.g., req.if_modified_since is a datetime object (of course
>> unparsed access is also available). Several objects like
>> response.cache_control are a bit more complex, since there's no data
>> structure that exactly represents them. I've tried to make them as easy
>> to use as possible for realistic web tasks.
> I'm interesting in something that's as lightweight as possible. Are
> there things that take a reasonable time to parse that could be put
> off until first use? Perhaps using properties to keep the simplest
> possible API (or perhaps not to emphasize the cost of first use)?
The only big parsing load is going to be the request payload;
processing top-level request headers is normally trivial,
I read Ian's concern as being about an API for setting / updating
cache-control response headers, because he found no natural mapping
for them as Python primitives.
Tres Seaver +1 540-429-0999 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Web-SIG