[Web-SIG] Inviting feedback on my proposed "ASGI" spec

[Andrew Godwin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160309/58f99a46/attachment.html>