On 15 October 2014 08:41, Antoine Pitrou <[email protected]> wrote: > On Wed, 15 Oct 2014 08:40:05 +1300 > Robert Collins > <[email protected]> wrote: >> On 15 October 2014 07:30, Antoine Pitrou <[email protected]> wrote: >> > On Tue, 14 Oct 2014 09:47:35 -0700 >> > Guido van Rossum <[email protected]> wrote: >> >> >> >> I'm wondering if a small extension to the WSGI protocol might be >> >> sufficient >> >> to support this: the special environ variable "wsgi.async_input" could >> >> optionally be tied to a standard asyncio stream reader ( >> >> https://docs.python.org/3/library/asyncio-stream.html#streamreader), from >> >> which bytes can be read using "yield from stream.read([nbytes])" or "yield >> >> from stream.readline()". >> > >> > I think it would be frankly better to hook at the transport/protocol >> > level, and let people wrap that inside an asyncio stream if that's their >> > preference. >> >> For things like mod_wsgi and uwsgi, we're not actually implementing >> the transport or protocol inside of Python at all - its all happening >> in C and often in an entirely separate process. > > You may have misunderstood me. I am talking about the Transport and > Protocol abstractions defined in PEP 3156.
Lets assume I did. Given say nginx + uwsgi + asyncio, you're proposing that there be a uwsgi-asyncio module that listens to the uwsgi socket and demuxes packets from that into something that then exposes a ReadTransport + WriteTransport pair and a Protocol on top of that. That Protocol would have a 1:1 correspondence with a WSGI request, and would *not* be HTTP itself but rather the subset that is exposed via uwsgi? -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
