[asterisk-dev] extensions.conf included contexts priorities

[Jared Smith]

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.

> 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)

> 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.

>
> 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.

-Jared