[Web-SIG] WSGI 2.0

[Phillip J. Eby]

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().