On Wed, Jun 7, 2017 at 7:05 PM, Tom Christie <christie....@gmail.com> wrote:
> Making some more progress - https://github.com/tomchristie/uvicorn > I'll look into adding streaming HTTP request bodies next, and then into > adding a websocket protocol. > > I see that the consumer interface is part of the channels API reference, > rather than part of the ASGI spec. > Is the plan to eventually include the consumer interface as part of the > ASGI spec, and make it more clearly separate to channels? > No, consumers as they are in Channels right now I see as a particularly Django thing (as they depend on Django-like things such as routing and the decorator suite). > > > > 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 sort of interface is exactly what I'm looking for, yes. From my POV > the consumer callable is the primary bit of interface, rather than the > channel layers. > > The consumer interface as it currently stands *is* sufficient for writing > alternative frameworks against, but it's possible that there could be a > more limited, refined interface to be had here. (Eg. limiting the message > argument to being something that contains only serializable data and > channel interfaces.) > > What would be great would be to have *just* the ASGI consumer callable > interface pulled into Django core, and have channels be one of the possible > ways of deploying against that. > Well, messages are already massively limited, but I agree it's potentially a better interface to have everyone develop against as a base. > > > persist state somewhere outside the locals() of the function (as you'll > still have separate coroutines for connect/receive/disconnect). > > I assume you'd use the name of the reply_channel as the key to the state > there, right? > > Incidentally asyncio implementations have less of a requirement here, as > you could write a single coroutine handler that's called on `connect`, > and that can then can non-blocking reads to a channel for incoming data, > and could support broadcast via an asyncio interface onto redis pub/sub. > > The problem here is that there isn't exactly one incoming channel for each WebSocket, so you can't listen within a consumer-like - they always have to be "takes a message, sends zero or more messages, exits" in terms of their pattern. This is semi-deliberate, as having sticky routing makes things way harder to scale, and the restriction about not allowing blocking-listening within a consumer makes deadlock way, way harder. Any interface like this would literally just be "this function gets called with every event, but you can't listen for events on your own"; HTTP request bodies being not an event, but a stream, and they're fine as they are deliberately on a special channel per request. 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/CAFwN1upg6do%2BcWCZD_35d_2T7iYgsn3xGvFtGaH_qC%2BcuMGk8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
