[Web-SIG] WebOb

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
simplification.

>> 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,
performance-wise.

I read Ian's concern as being about an API for setting / updating
cache-control response headers[1], because he found no natural mapping
for them as Python primitives.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9


Tres.
- --
===================================================================
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

iD8DBQFHHN3s+gerLs4ltQ4RAjytAKCNejjJahOz2Q3seKpE4pcRiZ4TCQCgu+J2
FFeSFhO84s9n25M2p3d0VWQ=
=szPr
-----END PGP SIGNATURE-----