[Web-SIG] (proto) request object spec

[Luke Arno]

On 11/10/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 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.

Usually, it is safer to have request object creation
non-destructive to the environment, if that is what
you are getting at. This is the current behavior of
YARO. I have "make destructive parsing of form
POST data an option" on my to-do list, though.
It currently uses StringIO to replace wsgi.input
and one might not always want that to happen
(big upload).

> >> 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 don't see the point. Sorry.

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

Even if we all do agree on the names of a couple
of things (and we probably can), what good does
it do? Has learning the request object interface
been a chronic problem for users? If so, is this
not more likely a reflection of shortcomings in
documentation rather than the need for a standard?

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

One _can_ do this and sometimes must but it is ugly.

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

That is my point. There are many smallish reasons to
prefer one request convenience interface to another. Why
try to sanctify some particular preferences? We don't
need it for interop because WSGI already gives us that.

Cheers,
- Luke