On Mon, Jun 12, 2017 at 10:53 PM, Tom Christie <christie....@gmail.com>
wrote:
> > def handler(channel_layer, channel_name, message):
>
> Oh great! That's not a million miles away from what I'm working towards on
> my side.
> Are you planning to eventually introduce something like that as part of
> the ASGI spec?
>
I had been pondering doing so for a while and I think this thread has
catalysed me to actually do it (and incorporate support for it into the
Channels/asgiref stuff too, so everything can use a common Worker class if
it's running in a separate process)
>
> > So is the channels object just a place to stuff different function
> handlers?
>
> No, it's just a different interface style onto exactly the same set of
> channel send/receive functionality.
> It's the difference between this:
>
> def hello_world(channel_layer, channel_name, message):
> ...
> channel_layer.send(message['reply_channel'], response)
>
> And this:
>
> def hello_world(message, channels):
> ...
> channels['reply'].send(response)
>
This is the sort of thing I would not put in a spec, but leave the
framework to do if it likes (the same way Django adds things like
message.reply_channel to the original message)
>
> > Why not just pass the channel layer there and use the API on that
> directly? e.g.: channel_layer.group_send("chat", message["text"])
>
> With the groups example I wanted to demonstrate that we don't need extra
> "extensions" API introduced onto the channel layer in order to support a
> broadcast interface.
>
Well the extensions are there for a reason :) But again, I think my goal in
ASGI is to provide a solid but not necessarily pretty base, and let things
build on top of it as they wish.
>
> > then frameworks can do per-channel-name dispatch if they like
>
> Yup, the channel name is certainly necessary.
> A possible alternative is including that in the message itself, which I
> also quite like as an option because you more naturally end up with a nice
> symmetry of having the signature of the child routes match the signature of
> the parent.
>
> def app(message, channels):
> channel = message['channel']
> if channel == 'http.request':
> http_request(message, channels)
> elif channel == 'websocket.connect':
> websocket_connect(message, channels)
> elif ...
>
> That's what I'm rolling with for the moment, but it's not something I'm
> necessarily wedded to.
>
I actually pondered this during the spec development (also considered
having a separate channel names dict inside, with the current name and
multiple reply names, e.g. "send" and "close"). Right now, I like the base
level interface as it is, because the ideological separation makes me
happier - you get out exactly what you put in, and there's no special
keyword to reserve - but the truth is that several of the backends actually
do this to support the process-local channels efficiently, so maybe it is
worth revisiting.
>
> I've done a bunch more work towards all this, so it'd worth checking out
> https://github.com/tomchristie/uvicorn in it's current state. That should
> make the interface style I'm considering more clear. (Focusing on asyncio
> there, but could equally present an equivalent-but-syncronous interface.)
>
>
I note that your examples do not include "receiving messages from a
WebSocket and sending replies" - I would love to see how you propose to
tackle this given your current API, and I think it's the missing piece of
what I understand.
> There are also now initial implementations for both WSGI-to-ASGI and
> ASGI-to-WSGI adapters.
>
>
There's a mostly-complete one in asgiref over here for WSGI-to-ASGI:
https://github.com/django/asgiref/blob/master/asgiref/wsgi.py
If you are feeling like it, I would love to have just one pair of canonical
adapters in the asgiref repo that everyone can use. The ASGI-to-WSGI
adapter can probably be written based on the callable pattern I described
at the top.
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+unsubscr...@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/CAFwN1uo2%2Bm63WKKN7MLYkbGj%3Duro%3D9-XcGcWmC-5DrQ4FO%2BGww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
