So, if I understand this example taken one step further would be:<br><br>[long-distance]<br>exten => _1NXXNXXXXXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})<br><div style="direction: ltr;">include => local<br><br>[local]<br>exten => _NXXXXXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
<br>include => no-priv<br></div><span class="q"><br>[no-priv]<br></span>exten => _NXXXXXX,1,Dial(no-permissions-to-make-this-type-of-call)<br>exten => _1NXXNXXXXXX,1,Dial(no-permissions-to-make-this-type-of-call)
<br><br>I started out disliking this method and trying to find a point of failure. I would conclude that its not the "intuitive" method, but it does seem to be functional. I would, if I were *entirely* new, expect the include=> to insert the values in the included context directly at that location. Consider me enlightened.
<br><br><div><span class="gmail_quote">On 4/24/07, <b class="gmail_sendername">Steve Murphy</b> <<a href="mailto:murf@parsetree.com">murf@parsetree.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2007-04-24 at 20:26 -0400, Jared Smith wrote:<br>> On 4/24/07, Steve Murphy <<a href="mailto:murf@parsetree.com">murf@parsetree.com</a>> wrote:<br>> > Trouble is, is this desired behavior? Or is having the contexts checked
<br>> > level by level until a match of any kind is found, the better procedure?<br>><br>> Well, I for one desire the current behavior. Everyone else can speak<br>> for themselves, but it makes it easy to override an extension included
<br>> in a more-deeply-nested extension by putting its replacement in a<br>> less-deeply-nested context. If they were all pulled together into one<br>> big ball of wax, we'd lose a lot of functionality.<br><br>
I'm glad to have this input! (It's actually easier to give the same<br>functionality).<br><br>><br>> > If you think choice (2) would be bad, I'd love to hear how you are<br>> > depending on the recursive behavior of the included patterns.
<br>><br>> Here's just one example of the many ways I use the current behavior.<br>><br>> [long-distance]<br>> exten => _1NXXNXXXXXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})<br>> include => local<br>>
<br>> [local]<br>> exten => _NXXXXXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})<br>> exten => _1NXXNXXXXXX,1,Dial(no-permissions-to-make-this-type-of-call)<br><br>**Murphy gasps in astonishment** This is very clever!!!
<br><br>How would you state this? I thought that this kind of search system<br>would be best taken advantage of by supplying more specific patterns at<br>the top levels, and having more general patterns below; this example is
<br>more like top levels getting<br>higher precedence than lower.<br><br>This example is really good, in that if just include the [local]<br>context, you'll get the message that you don't have perms to make<br>long-distance calls. But, including [long-distance] lets you dial
<br>long-distance, but without having to rewrite the [local] definitions.<br>**very** clever. OK. I'm sold.<br><br>><br>> > Jared's example is excellently obtuse! The inclusion tree looks<br>> > something like this:
<br>><br>> I'll take that as a compliment! It was carefully designed to<br>> stimulate thought and discussion.<br><br>You are taking it rightly, then! It's a well composed example. You could<br>do this for a living!! ;)
<br><br>><br>> ><br>> > foo +---+<br>> > (123) |<br>> > (456) |<br>> > (789) |<br>> > (_5XX) |<br>> > |<br>> > +-- bar ----------+<br>> > | (555) |
<br>> > | (_XXX) +--- baz-1<br>> > | (555)<br>> > | (333)<br>> > +-- baz-2<br>> > (555)<br>
> > (333)<br>> ><br>> > Worse yet, if you entered 333, and bar didn't have the _XXX pattern,<br>> > which would match, the baz-1 version, or the baz-2?<br>><br>> The one in [baz-1]. Again, when Asterisk looks in the bar context and
<br>> doesn't find a match, it looks in its included contexts, and would<br>> find a match in the [baz-1] context. Asterisk is going to look *all<br>> the way* through the [bar] context before moving on to the [baz-2]
<br>> context. If this doesn't qualify as depth-first search, I'm not<br>> seeing the reason why.<br><br>You are correct, this is fundamentally depth-first; it's just the fact<br>that it searches first all the way thru all the extensions defined in
<br>the current context, before recursion into the included context, that<br>gives it a breadth-first sort of taste. But only a taste. Or would it be<br>a nuance? A fragrance? A hint? A whisper? A touch? A dash? An<br>intimation? Oh, you know what I mean! I give up!
<br><br>murf<br><br><br><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br><br><br></blockquote></div><br>