Will asgi become a PEP like wsgi is ?

735 views
Skip to first unread message

Sebastian Haase

unread,
Mar 12, 2017, 9:16:40 AM3/12/17
to Django developers (Contributions to Django itself)
(sorry for cross-posting -  post should like be here rather than in django-users)
Hi,

wsgi is specified by
PEP 333 -- Python Web Server Gateway Interface v1.0

Django channels rely on asgi instead.
So far ASGI specs appear only here:

How do these two concepts compare in regards to their respect "importance" to the python community?
Especially under the consideration that real-time web applications (i.e. HTML5 websockets) is getting more and more important.

Regards,
Sebastian

Andrew Godwin

unread,
Mar 12, 2017, 9:42:38 PM3/12/17
to Django developers (Contributions to Django itself)
Hi Sebastian,

The proposal is certainly written like a PEP, and that is somewhat on purpose, but the scope and need for it are still a bit up in the air. In particular, ASGI currently specifies two parts:

 - An interface for talking to channel-based message queues and a set of guarantees and non-guarantees for them around delivery
 - A specification for encoding HTTP and WebSocket traffic on top of this interface as a set of messages

Given this, I would probably at a minimum want to separate the two of them out before thinking about approaching the PEP process with either part. The message queue abstraction is likely the harder one to get through as it is (deliberately) quite opinionated, but without it the other doesn't really make sense.

So, you see the quandry here, really. I just need to take the time and separate them and then start prodding people for feedback, I suspect, but anyone else on this list who has an opinion should definitely say something.

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2ee5ce83-1990-457a-b6d8-0b1db84e4b0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

James Pic

unread,
Mar 13, 2017, 7:09:19 AM3/13/17
to django-d...@googlegroups.com
I do not see myself using Django without Channels anymore, it's become a basic Django feature for me and I just love it. Despite my perhaps lack of knowledge about the protocol internals, such features seem like it would certainly benefit the Python community and anyway I'd say it's worth a try just to see what the python-ideas list has to say.

Etienne Robillard

unread,
Mar 13, 2017, 7:26:23 AM3/13/17
to django-d...@googlegroups.com

WSGI is for building web applications in Python.

ASGI is for building platform-oriented web applications in Django.

I'm -1 on this.

I prefer the ease and flexibility of WSGI draft over asynchronous platform choices.

E


Le 2017-03-13 à 07:08, James Pic a écrit :
I do not see myself using Django without Channels anymore, it's become a basic Django feature for me and I just love it. Despite my perhaps lack of knowledge about the protocol internals, such features seem like it would certainly benefit the Python community and anyway I'd say it's worth a try just to see what the python-ideas list has to say.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

James Pic

unread,
Mar 13, 2017, 7:50:31 AM3/13/17
to django-d...@googlegroups.com
On Mon, Mar 13, 2017 at 12:26 PM, Etienne Robillard <tka...@yandex.com> wrote:
> ASGI is for building platform-oriented web applications in Django.

Could you elaborate on this ? The only mention of Django I found in
the spec linked by the OT is "Django Channels ships with a no-op
consumer attached by default; we recommend other implementations do
the same", so it doesn't look really coupled with Django overall:
http://channels.readthedocs.io/en/stable/asgi.html

Etienne Robillard

unread,
Mar 13, 2017, 7:58:52 AM3/13/17
to jp...@yourlabs.org, django-d...@googlegroups.com
As far I know Django channels is a Django framework enforcing a specific
messaging protocol in mind.

I don't see how implementing ASGI could help to build more scalable apps
without breaking compatibility with WSGI.

E

James Pic

unread,
Mar 13, 2017, 8:11:57 AM3/13/17
to Etienne Robillard, django-d...@googlegroups.com
On Mon, Mar 13, 2017 at 12:58 PM, Etienne Robillard <tka...@yandex.com> wrote:
>
> As far I know Django channels is a Django framework enforcing a specific messaging protocol in mind.

Honnestly I thought the messaging protocol was just msgpack.

> I don't see how implementing ASGI could help to build more scalable apps
> without breaking compatibility with WSGI.
>

I thought ASGI could sit below WSGI without breaking compatibility.

James Bennett

unread,
Mar 13, 2017, 8:17:33 AM3/13/17
to django-d...@googlegroups.com, jp...@yourlabs.org
WSGI is a framework-independent protocol to allow HTTP servers to communicate with Python applications. It defines a standard API and serialization mechanism to be used by the HTTP server and the Python application in order to allow them to work together.

WSGI *only* does plain HTTP. And in fact it only does plain HTTP/1.1. It cannot handle quite a few features of HTTP/2, and provides no support whatsoever for modern bidirectional web protocols like WebSocket.

ASGI attempts to fill that gap by defining a protocol which allows these other protocols/features to communicate with Python applications. In much the same way as WSGI, it defines an API and serialization. There is nothing Django-specific about ASGI. ASGI is not coupled to Django. ASGI is just a necessary precondition for being able to build the kinds of things in Django that Channels aims to provide, in much the same way that WSGI -- or something like it -- is a necessary precondition for current request/response HTTP/1.1 Django to exist.

Andrew Godwin

unread,
Mar 13, 2017, 1:03:49 PM3/13/17
to Django developers (Contributions to Django itself), jp...@yourlabs.org
Right, what James says here is pretty much my thoughts; it has been designed from the ground up not to be tied to Django, up to and including the fact that it's in separate packages; all the Django-specific stuff is in the "channels" package, while daphne, asgi_redis, asgiref etc. are useable by anything (I need to look into getting another framework like Flask working on top of it as a proof of concept).

My main sticking point is the design of the ASGI messaging interface, as that will be the one thing that everyone has to write against - are the number of calls we have enough? Does async support fit in alright? etc. The message formats themselves would work on anything that looks remotely similar.

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages