At 07:56 PM 3/29/2007 -0500, Ian Bicking wrote: >Do we want to discuss WSGI 2.0? I added a wiki page here to list >anything anyone wants to discuss for 2.0: http://wsgi.org/wsgi/WSGI_2.0 > >I've listed the things I can remember, and copying here: > > >start_response and write >------------------------ > >We could remove ``start_response`` and the writer that it implies. This >would lead to a signature like:: > > def app(environ): > return '200 OK', [('Content-type', 'text/plain')], ['Hello world'] > >That is, return a three-tuple of (status, headers, app_iter). > >It's relatively simple to provide adapters to and from this signature to >the WSGI 1.0 signature.
I think we also want to have a value you can yield from the app_iter to explicitly request that the buffer be flushed, and that we should reopen the discussion about values to be yielded to communicate with async servers, indicating that the iterator should be paused pending input or some other operation. Ideally, this should be done in a way that's easy for middleware to handle; a flush signal should be handled by the middleware *and* passed up the chain, while any other async signals would be passed directly up the chain (unless it's something like "pause for input" and the middleware controls the input). If we do this right, it should be easier to write middleware that works correctly with respect to buffering, since the issues of flushing and pausing now become explicit rather than implicit. (This should make it easier to teach/learn as well.) >It's not clear if the app_iter must be used in the same thread as the >application. Since the application is blocking, presumably *it* must be >run all in one thread. This should be more explicitly documented. Definitely. I think that we should not require thread affinity between the application and the app_iter -- my feeling at this point is that actual yielding is an edge case with respect to most WSGI apps. The common case WSGI application should be just returning a list or tuple with a single string in it, and not doing any complex iteration. Allowing the server more flexibility here is probably the better choice. Indeed, I'm not sure we should require thread affinity across invocations of app_iter.next(). _______________________________________________ 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