At 06:52 PM 3/29/2007 -0400, James Y Knight wrote: >Perhaps a WSGI 1.1 fixing these issues would be a good idea?
I would personally rather see a WSGI 2.0 that also gets rid of start_response(), write(), and perhaps adds better async support. I suspect that the current approach to using yield boundaries to indicate buffer flushing should be replaced with yielding an explicit flush request object. WSGI beginners seem to think that write() and yield are like "print" in CGI, and thus end up writing code that performs crappily on compliant servers. In retrospect, the "server push" use case is much less common and it's reasonable to have to do something explicit to support it. Middleware would also be happier if it could tell when the application really wanted to flush the output. Combining this with some way to yield "pauses" to better support async servers would be ideal. It would also be nice if you could cleanly adapt WSGI 1.0 to 2.0 and vice versa, as long as you're using a reasonable subset (i.e. a subset that doesn't care about some of the quirks we need to fix). _______________________________________________ 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
