On 10 March 2016 at 13:34, Andrew Godwin <and...@aeracode.org> wrote:
> 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.

I realise this may sound bikesheddy, but it would be really good to
not call it ASGI. From your docs "
Despite the name of the proposal, ASGI does not specify or design to
any specific in-process async solution, such as asyncio, twisted, or
gevent. Instead, the receive_many function can be switched between
nonblocking or synchronous. This approach allows applications to
choose what’s best for their current runtime environment; further
improvements may provide extensions where cooperative versions of
receive_many are provided."

I'm worried that folk will assume a parallel between ASGI and asyncio,
but there appears to be none... which is only a problem due to the
room for confusion.


Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to