Right. I'll try and get a full async example up in channels-examples soon to show off how this might work; I did introduce a Worker class into the asgiref package last week as well, and the two things that you need to override on that are "the list of channels to listen to" and "handle this message".
While the consumer interface as it stands is tied into Django (where we _could_ allow coroutines, with some difficulty if I am to continue supporting Python 2.7 for Django 1.11), there's also room for asgiref to have either: - Something substantially similar to Django's consumer system, or - The ability to just plug in a callable/coroutine that gets called with messages as they arrive, and which provides you with channel names to listen on as an attribute This second one is perhaps my preferred approach, as it's getting very close to the design of WSGI, and it would not be hard to re-layer Channels to exist behind this pattern. I think at that point the main difference to WSGI is the need to persist state somewhere outside the locals() of the function (as you'll still have separate coroutines for connect/receive/disconnect). Andrew On Fri, Jun 2, 2017 at 8:21 AM, Tom Christie <christie....@gmail.com> wrote: > > I suspect there is potential for a very fast async-only layer that can > trigger the await that's hanging in a receive_async() directly from a > send() to a related channel, rather than sticking it onto a memory location > and waiting > > Yup. Something that the gunicorn worker doesn't currently provide is > `receive()/receive_async()` hooks, and instead current just rely on > `send()`ing every incoming message. For eg. HTTP the one thing that doesn't > give you so easily is request body buffering or streaming, but you *could* > handle that on the application side if you really wanted. > > I think that the sensible next step for me will be to work towards adding > that interface in, at which point we ought to have an implementation > capable of running a Django service using ASGIHandler. (And yeah, I see > that you'd be adding channel queues at that point.) ayncio.Queue is looking > like a mightily useful bit of tooling right now. > > > the design of an ASGI-direct protocol > > I think the important part of this is "how does asyncio code look in the > context of an ASGI consumer interface" rather than specifics about > server-direct-to-consumer configurations. Not unreasonable that an "An > asyncio ASGI app, running behind a full channel layer" could be a thing > too, in the future. > > Perhaps a good way of narrowing this down would be to consider an asyncio > runworker: Is the application responsible for pushing coroutines onto the > event loop (advantage: more narrowly scoped), or do you extend the ASGI > consumer callable definition to also allow it to be a coroutine > (advantages: more natural interface, server can manage task cancellations). > > -- > 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/ms > gid/django-developers/16f87149-6896-40a2-a1fd-028446a171a3% > 40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/16f87149-6896-40a2-a1fd-028446a171a3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFwN1uqqXFc7tKfU4b3uL%3DGdPUBNHBAS1aURP15Sa56nmT2czg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
