<div dir="ltr">Hi all,<div><br></div><div>As some of you may know, I've been working over the past few months to bring native WebSocket support to Django, via a project codenamed "Django Channels" - this is mostly the reason I've been involved in recent WSGI discussions.</div><div><br></div><div>I'm personally of the opinion that WSGI works well for HTTP, with a few improvements we can roll into a 1.1, but that we also need something else that can support WebSockets and other future web protocols (e.g. WebRTC components).</div><div><br></div><div>To that end, I did some work to make the underlying mechanism Django Channels uses into more of a standard, which I have codenamed ASGI; while initially I intended for it to be a Django documented API, as I've gone further with the project I've come to believe it could be useful to the Python community at large.</div><div><br></div><div>My intention would be for this spec to sit alongside WSGI, and be a second option for both servers and frameworks to support (if they wished) that supports both HTTP and WebSocket connections, as well as a reasonable way to extend it to future protocols.</div><div><br></div><div>All current applications and servers could continue to work via adapter classes that transform ASGI to WSGI on either end of its HTTP path, which I think is an important migration consideration.</div><div><br></div><div>I'd love some feedback from this group on my proposed specification, and any major problems you forsee; there are a few issues I know about, mostly potential performance issues, but in most of those cases I believe the gains outweigh the loss. The major change is that servers and applications now run independently, either in separate threads or processes, and communicate bidirectionally over a "channel layer", rather than the server calling the application directly.</div><div><br></div><div>I'm not yet angling to take this to a PEP, but that would be my eventual goal; right now, I want to get feedback from people on their major likes/dislikes, and how it works for various parts of the Python web ecosystem.</div><div><br></div><div>The spec already has an application framework (Django), web/websocket server (Daphne [1]) and three channel layers [2] implemented, so I've ironed out some major problems it initially had from working on those, but I'm not as experienced in the rigours of serving HTTP as most of you are. I do encourage you, though, to take a look at the rest of the Channels docs if you want to get an idea of how it works and deploys in practice.</div><div><br></div><div>Spec is up here: <a href="http://channels.readthedocs.org/en/latest/asgi.html">http://channels.readthedocs.org/en/latest/asgi.html</a></div><div><br></div><div>Helpful quick Q&A: <a href="http://channels.readthedocs.org/en/latest/inshort.html">http://channels.readthedocs.org/en/latest/inshort.html</a></div><div><br></div><div>I do believe that making a clean break from WSGI to a new structure (and NOT calling it "WSGI 2") is the best thing we can do if we truly want to support more web protocols properly, and I believe that doing that in a way that still supports WSGI and provides a nice migration path is important - I believe ASGI provides both of these things, as well as a relatively simple core API (one of WSGI's strengths in my opinion) - but I welcome your opinions as well.</div><div><br></div><div>Andrew</div><div><br></div><div>[1] <a href="https://github.com/andrewgodwin/daphne">https://github.com/andrewgodwin/daphne</a></div><div>[2] <a href="https://github.com/andrewgodwin/asgi_redis">https://github.com/andrewgodwin/asgi_redis</a>, <a href="https://github.com/andrewgodwin/asgiref/blob/master/asgiref/inmemory.py">https://github.com/andrewgodwin/asgiref/blob/master/asgiref/inmemory.py</a>, <a href="https://github.com/andrewgodwin/channels/blob/master/channels/database_layer.py">https://github.com/andrewgodwin/channels/blob/master/channels/database_layer.py</a></div></div>