2009/8/4 P.J. Eby <p...@telecommunity.com>: > At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote: >> >> Would this be a new PEP or a revision? I think it should be a new >> PEP, as WSGI 1 remains valid and the same as it always was, and PEP >> 333 describes that. > > +1 for a new PEP, since we'd be able to drop a lot of crufty examples and > explanations about the cruddy bits. wsgiref should add 1->2 and 2->1 > adapters. (Although technically, running a WSGI 1 application in a WSGI 2 > server requires either threads or greenlets.) > > IMO, the main benefit of implementing WSGI 2 is to applications, not > servers, with the possible exception of async servers (e.g. Twisted) that > would prefer an iterator-only communications mode. Such servers could > refactor their WSGI 1 support into a (thread or greenlet-based) WSGI 2->1 > adapter. > > Synchronous servers, OTOH, might as well stay WSGI 1, and simply use a > standard 1->2 adapter to support WSGI 2.
Personally I don't believe we should be trying to support async servers in the WSGI specification. Leave it simple and cater for the predominant case rather than make it complicated just to support what is going to be a minority deployment. It was async servers that got the whole discussion derailed last time. Leave input stream as is now as it is a known quantity and shown through actual use to work acceptably. Changing to an input iterator in my mind introduces too many unknowns around how input buffering is going to behave. In worst case you could really screw up performance because of a trickle of input coming into an application where no way for an application to control block size of what is read. Let us find some other way of supporting async servers, but not by changing WSGI interface itself. Graham _______________________________________________ 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
