Hi all, 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.
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). 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. 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. 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. 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. 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. 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. Spec is up here: http://channels.readthedocs.org/en/latest/asgi.html Helpful quick Q&A: http://channels.readthedocs.org/en/latest/inshort.html 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. Andrew [1] https://github.com/andrewgodwin/daphne [2] https://github.com/andrewgodwin/asgi_redis, https://github.com/andrewgodwin/asgiref/blob/master/asgiref/inmemory.py, https://github.com/andrewgodwin/channels/blob/master/channels/database_layer.py
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com