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