[Web-SIG] WSGI 2

[P.J. Eby]

At 10:48 AM 8/4/2009 +1000, Graham Dumpleton wrote:
>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.

I'm not suggesting adding anything for async servers; I'm just saying 
that they will likely prefer to use WSGI 2 and use a 2->1 adapter to 
do WSGI 1 support, whereas synchronous servers will likely prefer the reverse.

The WSGI spec doesn't currently require streaming upload support, so 
if an async server wants to buffer the input (e.g. to a temp file) 
rather than trusting the application to handle reads, it's free to do 
so.  (And that's independent of whether it's WSGI 1 or 2 being used.)