[Web-SIG] WSGI - alternate ideas, part II

[Phillip J. Eby]

At 11:06 PM 9/15/04 -0400, Peter Hunt wrote:

>Thus, here is my "WSGI-X" proposal. The application will call the
>gateway, opposite of WSGI. For example, a CGI WSGI-X application may
>begin with:
>
>#!/usr/bin/env python
>if __name__ == "__main__":
>       from wsgix import cgi
>       req = cgi.get_request()

That's pretty hard to implement correctly in any number of 
servers.  Really, pretty much every server wants to call the application, 
rather than the other way around, because servers want to use their own 
event loop.


>stdout - the raw, unbuffered direct output stream to the client

So, header parsing is required?  Or are only 'nph-' CGI scripts allowed?


>Now we have a basic interface to interact with HTTP. If one wants to
>write an extension to provide services like simplified cookie
>handling, sessions, or buffered headers and content, they write an
>extension function. A simple one for cookies would look like:
>
>def cookie_extension(req):
>       if not hasattr(req, "cookie"):
>             req.cookie = 
> Cookie.SimpleCookie(req.environ.get("HTTP_COOKIE",""))

Note that this can easily be accomplished in WSGI, by changing 
'hasattr(req,"cookie")' to '"my_extension.cookie" in environ' and 
'req.cookie' to 'environ["my_extension.cookie"]'.


>It modifies the request object if it hasn't already been modified.
>This saves us a bit of overhead so we won't need to parse the cookie
>again in case it is called twice (as it will if other extensions
>depend on it).

Also achievable within 'environ'.



>Finish hooks have the same signature and execute when
>the finish() method is called. For example, a buffering extension
>would flush the buffer. Extensions can also add methods to the request
>object, for items such as add_header().

Under WSGI, such "finish" hooks can be rendered as a 'close()' method on an 
iterable by a piece of middleware.