[Web-SIG] WSGI 2.0

[Phillip J. Eby]

At 03:47 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Ian Bicking ha scritto:
> > PJE wants to talk about WSGI 2.  That's cool; I remind everyone that
> > there's a page to bring up issues you might want to discuss for 2.0:
> > http://wsgi.org/wsgi/WSGI_2.0
> >
> > Feel free to add to, or discuss, issues on that page...
> >
>
>I'll write my ideas here:
>1) start_response should no more return a write callable.
>     I don't know how many application use it, but I think that
>     I can't implement it in a conforming way for nginx mod_wsgi,
>     so I will not implement it.
>
>2) start_response should no more accept a exc_info parameter.
>     I don't know how many applications use it, but I think that
>     WSGI applications should not change their mind.
>     They should delay calling start_response until they are able
>     to produce a "final" response.
>
>3) start_response should accept, as an optional parameter, a
>     flush argument.
>     flush default to False, and when it is True, the WSGI gateway
>     must write the headers as soon as start_response is called.

WSGI 2.0 does not have a start_response() callable in the first 
place, so none of these apply.

In WSGI 2.0, an application looks like this:

     def an_app(environ):
         return "200 OK", [('content-type', 'text/plain')], ["Hello, world!"]

i.e., no start_response(), no write(), no statefulness at all.  It 
just returns a tuple of (status, headers, iterable), where all three 
are defined by the WSGI 1.0 spec.

The third item in the tuple is a WSGI 1.0 app_iter, so it can be a 
generator, have a close() method, etc.  Here's a WSGI 1 middleware 
application that converts a WSGI 2 application to WSGI 1:

         def wsgi_1_app(environ, start_response):
             status, headers, body = wsgi_2_app(environ)
             start_response(status, headers)
             return body

In other words, WSGI 2 is basically WSGI 1 with start_response() and 
write() taken out.


>4) the environ dictionary should have a new WSGI-defined variable:
>     wsgi.asynchronous.
>     This value should evaluate to true when the server is asynchonous,
>     that is, the WSGI application is executed in the main process loop
>     of the server and the WSGI application can be paused after it yields
>     some data.

It's always the case that a WSGI application can be paused after it 
yields data, even in WSGI 1.0.