[Web-SIG] WSGI 2.0
Phillip J. Eby
pje at telecommunity.com
Fri Mar 30 04:41:12 CEST 2007
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
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
More information about the Web-SIG