[Web-SIG] (proto) request object spec

[Ian Bicking]

Luke Arno wrote:
> If I understand you: if I tack some environ values on
> to my request object and the user changes those
> value on the request object, this must automatically
> be reflected in the environ. Is that right?
> 
> If so, I disagree. If the user wants to change the value
> of something in the environ, she can do so. If not that
> is fine. I would rather say "no auto-magical updates!"

I'm not really clear what you're thinking.  I guess I mean something 
like this is bad:

class Request(object):
     def __init__(self, environ):
         self.environ = environ
         self.params = parse_params(environ)

Now the request has a parsed form of the parameters (e.g., query 
string), and if you recreate it then you'll have problems getting the 
parameters again.

This particular case is the motivation for the form_vars spec.


>> In addition to this very minimal set of requirements for a request
>> object, the specification could have a kind of style guide for request
>> objects.  No request object would have to conform, and it would not be
>> intended to ensure interoperability.  The style guide would just be to
>> increase familiarity of developers when they encounter a new request 
>> object.
> 
> The whole point of a request object is to provide a more
> friendly and to-taste interface to cover the universal but
> decidedly (and necessarily) clunky WSGI interface. If
> we specify a style guide, many will feel compelled to
> conform to it. This seems counterproductive when the
> very purpose is to meet diverse preferences.

Well, if it's a style guide then no one is forcing you to follow it. 
But if you don't care one way or the other, you can conform to something 
just because.

I would assume the style guide would address the really 
consistent/boring stuff, like form parameters and a few typical keys 
like method and path_info.

If you want, you can provide multiple ways to get to the same thing, or 
one way that doesn't fit the style guide; which will be typical when 
backward compatibility is a concern.


> Though the similarity of request objects out there (note
> that I called mine "Yet Another Request Object") gives
> the appearance of a prime candidate for standardization,
> the subtle (or not) differences are very important to
> people in this area. It is sort of like the chair. It is a lot
> like the chair, actually: you are in it all day and it needs
> to be adjustable and fit just right.
> 
> If this were a good candidate for standardization, I
> think WSGI would look a whole lot different.

I thought this way as well, but when the scope of the request object is 
strictly confined to the WSGI environment I think it makes it a lot 
easier.  Not everyone will want to use that; for variety of small 
reasons I think this is only going to be appealing to WSGIish 
frameworks.  But it's opt-in, so whatever.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org