[asterisk-dev] extensions.conf included contexts priorities

[Steve Murphy]

On Tue, 2007-04-24 at 20:26 -0400, Jared Smith wrote:
> On 4/24/07, Steve Murphy <murf at parsetree.com> wrote:
> > Trouble is, is this desired behavior? Or is having the contexts checked
> > level by level until a match of any kind is found, the better procedure?
> 
> Well, I for one desire the current behavior.  Everyone else can speak
> for themselves, but it makes it easy to override an extension included
> in a more-deeply-nested extension by putting its replacement in a
> less-deeply-nested context.  If they were all pulled together into one
> big ball of wax, we'd lose a lot of functionality.

I'm glad to have this input! (It's actually easier to give the same
functionality).

> 
> > If you think choice (2) would be bad, I'd love to hear how you are
> > depending on the recursive behavior of the included patterns.
> 
> Here's just one example of the many ways I use the current behavior.
> 
> [long-distance]
> exten => _1NXXNXXXXXX,1,Dial(IAX2/${UPSTREAM}/${EXTEN})
> include => local
> 
> [local]
> exten => _NXXXXXX,1,Dial(IAX2/${LOCALPROVIDER}/${EXTEN})
> exten => _1NXXNXXXXXX,1,Dial(no-permissions-to-make-this-type-of-call)

**Murphy gasps in astonishment**  This is very clever!!!

How would you state this? I thought that this kind of search system
would be best taken advantage of by supplying more specific patterns at
the top levels, and having more general patterns below; this example is
more like top levels getting 
higher precedence than lower.

This example is really good, in that if just include the [local]
context, you'll get the message that you don't have perms to make
long-distance calls. But, including [long-distance] lets you dial
long-distance, but without having to rewrite the [local] definitions.
**very** clever. OK. I'm sold.

> 
> > Jared's example is excellently obtuse! The inclusion tree looks
> > something like this:
> 
> I'll take that as a compliment!  It was carefully designed to
> stimulate thought and discussion.

You are taking it rightly, then! It's a well composed example. You could
do this for a living!! ;)

> 
> >
> > foo +---+
> >  (123)  |
> >  (456)  |
> >  (789)  |
> >  (_5XX) |
> >         |
> >         +-- bar ----------+
> >         |    (555)        |
> >         |    (_XXX)       +--- baz-1
> >         |                        (555)
> >         |                        (333)
> >         +-- baz-2
> >              (555)
> >              (333)
> >
> > Worse yet, if you entered 333, and bar didn't have the _XXX pattern,
> > which would match, the baz-1 version, or the baz-2?
> 
> The one in [baz-1].  Again, when Asterisk looks in the bar context and
> doesn't find a match, it looks in its included contexts, and would
> find a match in the [baz-1] context.  Asterisk is going to look *all
> the way* through the [bar] context before moving on to the [baz-2]
> context.  If this doesn't qualify as depth-first search, I'm not
> seeing the reason why.

You are correct, this is fundamentally depth-first; it's just the fact
that it searches first all the way thru all the extensions defined in
the current context, before recursion into the included context, that
gives it a breadth-first sort of taste. But only a taste. Or would it be
a nuance? A fragrance?  A hint? A whisper? A touch? A dash? An
intimation? Oh, you know what I mean! I give up!

murf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070424/3709f6cf/smime.bin