[Web-SIG] WSGI 2

[Graham Dumpleton]

2009/8/4 P.J. Eby <pje at 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