[asterisk-dev] extension ordering

[Tilghman Lesher]

On Sunday 22 January 2006 12:52, Luigi Rizzo wrote:
> i noticed that the ordering of extensions in the
> internal lists is determined by a strcmp(), which means
> that if a string is a prefix of another,
> the prefix comes first.
>
> Is there a reason for this ? because it seems contrary
> to what is at least common practice in IP routing
> (longest prefix match first), and it would seem
> convenient to me that in a dialplan you have exceptions first
> and a general rule afterwards...

We do have exceptions first and general rules afterwards.  Patterns
always come last; exact matches are searched first.  Now the exact
matches are always in alphanumeric order, because if they match, they
are ALWAYS preferred above a pattern (and they always match EXACTLY).

We could certainly optimize the order for exact matches, so the ones
which are dialled most sit at the top of the foodchain, but I doubt
that will make a big difference.  Most dialplans spend most of their
time in patterns, not in exactly matched extensions.

Something we might want to do is to do a bit better on the sort, since
it only happens at load time.  I think better patterns (patterns with
less possibilities for each digit) should rate better than more
ambiguous patterns.  For example, currently X rates better than Z,
when X is any of 10 digits, but Z is any of only 9.  And classes ('[]'
notation) should match better than N, Z, or X, when they specify less
than 8 digits (currently classes fall below all of these, since '['
comes after 'Z' in the ASCII table).

However, this doesn't work as well if you're loading extensions from a
database, since there isn't a very portable way of sorting results
(let alone matching the pattern in the statement handle) for
retrieval.  This means that if we're looking for a dialplan that
behaves the same no matter where we're storing the extensions, we
pretty much need to stick with something portable like strcmp().

-- 
Tilghman