Yes, my intent is that "path" is just a stand-in for "any string key in a
message", thus you could route other ways (for example, `method` in
http.request, though that's probably not super useful inside Django).
Andrew
On Sat, Mar 19, 2016 at 1:40 PM, Vincent <thebeach...@gmail.com> wrote:
> Andrew,
>
> Thanks for the explanation.
>
> (re: including based only on path, routing based on channel (and
> optionally path?)), I really really like that simplicity, the more I think
> about it.
>
> Expanding on that to include your prior examples, I'm assuming `path` is
> just incidental for http / websocket, and that other kwargs would be
> relevant for `include`:
>
> routing = [
> # Catches any US phone number and delegates to myapp.us.routing.routing
> include('my_us_app.routing', sender=r'\+1(?P<local_number>[0-9]+)$'),
>
> # Catches any UK phone number and routes to UkSmsConsumer
> route('sms.receive', sender=r'\+44(?P<local_number>[0-9]+)$',
> UkSmsConsumer),
> ]
>
> Is that right?
>
> On Friday, March 18, 2016 at 5:18:51 PM UTC-4, Andrew Godwin wrote:
>>
>> 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 <thebe...@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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/67476f8c-6cce-428d-93bd-562ffaabe2ff%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/67476f8c-6cce-428d-93bd-562ffaabe2ff%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/CAFwN1upwLekaYRZ69wKOJTbJfM_3f1_-4kdS6vFXJD8wssec6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
