[asterisk-dev] [design] Matching algorithm

[Tilghman Lesher]

There is a bug that has been filed, number 12777, which describes a possible
bug in the current matching algorithm.  I say possible, because it could also
be seen as a feature.

Historically, in 1.2 and previous versions, the pattern matching was done
based upon ASCII sorting.  That is, "_1" sorted before "_X", so "_1" matched
before "_X".  This broke down from what people expected when you take into
account class-based matching, such as "_[1-4]".  Since "X" occurs earlier in
the ASCII table than "[", "_X" matched before "_[1-4]".

This was changed in 1.4, such that each class matched as if it were a single
entity and more specific matches matched first.  So the last example reversed
the sorting priority order, "_[1-4]" now matches before "_X".

In the matching code, however, there is an anomaly, in that if you use the
lowercase versions of the common classes, that is "n", "x", and "z", they
currently match earlier than more specific matches.  That is, "_x" matches
before "_[1-4]", which matches before "_X".

Now, we are not going to change this behavior in 1.4, certainly.  That has the
potential to break currently working dialplans, and where we can reasonably
foresee such an outcome, we'd like to avoid that.

However, this is certainly an unintended behavior, and the question then
becomes, do we document this as a way to override the pattern match
algorithm, or do we change the lowercase class letters to behave the same
as the uppercase class letters?

I open the floor to more discussion.

-- 
Tilghman