Re: [Web-SIG] WSGI - alternate ideas, part II
I think that the application should be passed a finish() method as a
parameter or start_response return value. If the WSGI application is
not a generator and returns wsgi.NOT_DONE_YET (similar to
Twisted.web's NOT_DONE_YET), it is required to call finish().
Otherwise, the gateway will call finish() after the generator is
finished or a string value is returned.
That way, one could do all of the deferred calls they want, and simply
return NOT_DONE_YET and call finish().
How does that sound?
On Wed, 15 Sep 2004 23:27:18 -0400, 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.
participants (3)
-
Mary Gardiner
-
Peter Hunt
-
Phillip J. Eby