[Web-SIG] (proto) request object spec

[Luke Arno]

On 11/10/06, Ian Bicking <ianb at colorstudy.com> wrote:
> To clarify my note about a standard request object in my last email,
> here's the basic framework of the spec I imagine:
>
> A request object conforming to this specification will have a .environ
> attribute.  This will be the WSGI request environment.
>
> The request object will also not store any state internally.  All state
> will be stored in the WSGI request environment.  If the environment is
> extracted and the request object recreated, then the resulting new
> request object should be entirely equivalent to the original request object.
>
> This makes it easy to get the request object *you* want, given a request
> object you may not want.  The state requirement means intermediaries may
> change the request object without any loss of information.  If a request
> object stores information in a non-standard key, then that information
> may not be directly exposed in other request objects, but it's not
> hidden and it is recoverable.

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!"

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

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.

Cheers,
- Luke