<br><br><div class="gmail_quote">On Mon, Jun 15, 2009 at 3:11 PM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com">mmichelson@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi list,<br>
<br>
Before Asterisk 1.6.0 was released, Steve Murphy did quite a bit of work to<br>
create a new method of executing the pattern-matching for extensions in the<br>
dialplan.<br>
<br>
The biggest change he made was to change the structure used to store extensions<br>
from a linked list to a "trie." The use of this storage method means that the<br>
running time for looking up an extension is no longer bounded by the number of<br>
extensions in the dialplan but rather by the length of extensions in the<br>
dialplan. For installations with hundreds or thousands of extensions, this<br>
change means a remarkable improvement in lookup speed.<br>
<br>
The 'extenpatternmatchnew' option debuted in Asterisk 1.6.0, but it was disabled<br>
by default. It was disabled because it hadn't gone through all the tweaking and<br>
testing that the old pattern-matching had been through and possibly due to the<br>
knowledge of unfixed bugs.<br>
<br>
Since then, there have been several fixes to extenpatternmatchnew to improve its<br>
pattern-matching accuracy. I think it has reached a point where we should take<br>
the next logical step and consider making extenpatternmatchnew the standard.<br>
<br>
I think this can be accomplished through the following steps:<br>
<br>
1. Write a module for the tests/ directory which can take a sample dialplan and<br>
sample input, and tell which extension in the dialplan was matched given the input.<br>
<br>
2. Test many inputs against many dialplans, making sure that the new pattern<br>
matching algorithm results in the same pattern being matched by the old<br>
algorithm. Community-submitted dialplans would be great for this because you can<br>
test against patterns you may not have thought of yourself.<br>
<br>
3. If (2) results in bugs being found, submit issue reports and get the problems<br>
fixed. When the bugs are fixed, re-run all the tests from (2) to be sure there<br>
are no regressions from the bug fixes.<br>
<br>
4. Once it is determined that the new algorithm is matching the same patterns as<br>
the old, then change the default option in extensions.conf.sample for<br>
extenpatternmatchnew and change the default setting for it in the code. Commit<br>
the change.<br>
<br>
At this point, extenpatternmatchnew will be enabled by default for future<br>
versions of Asterisk. However, since all that testing was done to determine that<br>
the new pattern matching algorithm matches just as accurately as the old one,<br>
there's really no reason to keep the old code around.<br>
<br>
5. Remove all code dealing with the old pattern-matching method. Remove the<br>
extenpatternmatchnew option since it now is the standard.<br>
<br>
6. Re-run all the tests in 2, fixing any regressions found.<br>
<br>
7. Commit the code changes.<br>
<br>
Now for the catch. Even though I am presenting this project to the mailing list<br>
and laying out the steps necessary to get the project done, I just don't have<br>
the time to dedicate myself to this task. The difficulty of this project is such<br>
that it can't really be called a "janitor project" but it's small enough that I<br>
don't think you'd necessarily have to be an Asterisk development guru to finish<br>
it successfully.<br>
<br>
If there are interested parties, speak up! This is a good opportunity for you to<br>
get more involved in Asterisk's development.<br>
<br>
Mark Michelson<br>
</blockquote><div><br> </div></div>I'll be happy to serve as a resource here! I can answer questions,<br>offer advise, and provide a shoulder to cry on. You may have to<br>provide the towel, tho!<br><br>murf<br><br clear="all">
<br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>