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. 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. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
