[asterisk-dev] extension ordering

[Luigi Rizzo]

On Sun, Jan 22, 2006 at 10:28:40PM -0600, Tilghman Lesher wrote:
> 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

you know perfectly that 'exception' is not a synonym of 'exact match',
you could have (as in the case i was trying to address) exceptions
for a company or a given area code where you do need to
write something like _050221. for company X, and then _050. for all
numbers in area code 050, and then _0[1-9]. for all national fixed
phone calls, etc.

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

so do i, and this is why i asked :)

i know i can (this would be a trick directed to -users) force the
order by playing with ranges, and e.g. write

   exten => _0[5]0221., ...
   exten => _0[91-8]., ...

and make sure that the more specific one comes first, but, well...
it's ugly!

Anyways i don't see why we are forced to use strcmp() to compare extensions.
As a matter of fact, we are already using our own extension comparison
routine, which first compares the initial character to see if they
are '_' or something else, and then looks at strcmp.
It is trivial to write a comparison routine that does the above plus
onforces a sort order on classes and wildcards depending on our
desired behaviour (e.g. on pattern length, elements in each class, etc.),
and not on artifacts of the ascii table.

The problem is how much do existing dialplans rely on the
ordering of extensions...

	cheers
	luigi

> 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
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev