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. _______________________________________________ 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