I like most of it apart from the fact you can set a consumer to consume ANY channel, which seems incredibly dangerous - when a channel is wrongly consumed the only visible error is usually just a lack of response to the end client, and no two channels have messages that are similar in any useful way.
I think include should never need a channel, and route should always need one - which means the router always knows that every entry has exactly one channel defined that can be matched against. Andrew On Fri, Mar 18, 2016 at 5:43 PM, Vincent <thebeach...@gmail.com> wrote: > Andrew, > > Ah, excellent. I just took a short break (too many LOC at work today), and > while I was away I was thinking about all of this. > > Here's what I came up with: > > https://gist.github.com/orokusaki/17b4cf734b4d2f2af117 > > On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote: >> >> >> >> On Fri, Mar 18, 2016 at 4:40 PM, Vincent <thebe...@gmail.com> wrote: >> >>> Hey Andrew, >>> >>> Thanks for looking through all that, and for the reply. >>> >>> I like the simplicity of your updated examples. I started to make a >>> counter-example to suggest that `include` be inside of a `route` ( >>> https://gist.github.com/orokusaki/c0c934013ee7911071ef). >>> >>> But then, as I thought through this, I think I like your example almost* >>> exactly like it is, but I'm afraid there might be a problem: >>> >>> Given your example, any message how would a 'websocket.connect' message >>> at the path `notifications/foo/` be routed, giving this example: >>> >>> routing = [ >>> route("websocket.connect", ChatConnect), >>> include(path="^notifications", "notification.routing.routing"), >>> ] >>> >>> Given that the chat route is the first match, wouldn't the notifications >>> route never be used? Would path need to be required, so that the matching >>> would be similar to `urlpatterns`? Otherwise, we're allowing routing based >>> on channel name or path again? Maybe I'm misunderstanding. >>> >>> >> My idea there was that, like urlpatterns, it would go down the list in >> order, so if you did it like this: >> >> routing = [ >> include("notification.routing.routing", path="^notifications"), >> route("websocket.connect", ChatConnect), >> ] >> >> Then it would check the include first, before hitting the catchall. This >> is what you have to do with catchall URLs now, so I don't think it will be >> too unusual. >> >> 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/9ce52a05-88d6-412f-9cfe-59c600c35df7%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/9ce52a05-88d6-412f-9cfe-59c600c35df7%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/CAFwN1upU7HMCZ2r1Qsb8mm0QAQEwFXH3K5GS2tpnsu5a-0Rn4A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
