> 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"
Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, since the channel reader would be a coroutine. Which makes for interesting design thinking if you want to provide an consumer interface that's suitable for both framework styles. > HTTP request bodies being not an event, but a stream, and they're fine as they are deliberately on a special channel per request. Which it turns out actually makes the cooperative-tasks in a single-process implementation slightly awkward. (Doable, but rather more complex) For the purposes of my implementation it makes sense that if you've got a synchronous HTTP callable, then the server should buffer the incoming data and only dispatch a single message. (Not a problem wrt. Django, since ASGIHandler ends up effectively doing that in any case.) Anyways, thanks for talking through all this - it's been immensely helpful! - T :) -- 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 [email protected]. To post to this group, send email to [email protected]. 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/09684194-cc32-41c1-8073-7838c468c938%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
