<br><br><div class="gmail_quote">On Tue, Feb 16, 2010 at 3:01 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</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;">
<br>
16 feb 2010 kl. 09.43 skrev Tzafrir Cohen:<br>
<div><div></div><div class="h5"><br>
> On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:<br>
>> On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri <<a href="mailto:lenz.loway@gmail.com">lenz.loway@gmail.com</a>> wrote:<br>
>><br>
>>> Yes but in any case you can enter all of the strings that reasonably match<br>
>>> - even if you have variable-length numbers, you will be able to determine<br>
>>> that a valid number be between 5 and 15 characters - or likely 2 to 20, all<br>
>>> numbers. A number of 156 characters is very likely to be a problem.<br>
>>><br>
>><br>
>> This is probably a stupid idea, because it could only be implemented in<br>
>> trunk, and won't help with current implementations,<br>
>> and I suggested it a long time ago already when I did the fast pattern<br>
>> matching code, but I don't THINK it would be all that<br>
>> hard to offer SOME regex syntax in patterns to help reduce the impact of<br>
>> these kinds of problems.<br>
>><br>
>> Like using:<br>
>><br>
>> [incoming-from-voip]<br>
>> exten => _X\{7-10\},1,Dial(${EXTEN}@incoming-from-voip-old)<br>
>><br>
>> instead of :<br>
>><br>
>> [incoming-from-voip]<br>
>> exten => XXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)<br>
>> exten => XXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)<br>
>> exten => XXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)<br>
>> exten => XXXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)<br>
>><br>
>> I put the \'s in front of the {}'s because we probably wouldn't want to<br>
>> change the<br>
>> behavior of exact matching, and there's some precedent for using such stuff<br>
>> in some implementations of regex, where \< matches the beginning of a word,<br>
>> etc.<br>
>><br>
>> and, of course there would be the shorthand variants \{7-\} for seven or<br>
>> more; \{-10\} for 1-10.<br>
>> Some might argue 0-10. Whatever.<br>
>><br>
>> I THINK this could be implemented in both the fast pattern matcher and the<br>
>> current slow one. I know it wouldn't be that bad to do in the fast pattern<br>
>> matcher.<br>
>> I hadn't really given the slow one (the current one) much thought.<br>
><br>
> I think it would be very useful. One small point:<br>
><br>
> The '.' is short. This helps making it pupular. X\{1-\} is much less<br>
> so.<br>
><br>
> Another thing that I think would help: an equivalent of perl's \w:<br>
> something similar to 'X', but also matches letters. This is syntactic<br>
> sugar, but we need such sugar for readable dialplans.<br>
><br>
</div></div>Leif and I had a proposal years ago for an "alphaexten" that used perl regexps.<br>
<font color="#888888"><br></font></blockquote><div><br>Yes, I know that many have proposed full regex and regex-like extensions for<br>the dialplan patterns, but there's one big rub. The current pattern matcher is light and<br>
fast compared to a full regex matcher. The restrictions on constructs make it a fairly<br>fast linear matcher without any loops or recursive behavior to slow it down. We can currently use<br>rules to quantify the "best match" that makes it fairly predictable, and the work on a<br>
fast pattern matcher (O(log(pattern length)) instead of O((num patterns)^2) was possible.<br><br>But, when you move to full regex approaches, you lose all those nice properties. You'd have<br>to move to a 'best match first' sort of strategy, so you can move from a O(n^2) type scenario,<br>
and you lock yourself into an O(n^2/2) scenario. For large dialplans on a busy system, you are<br>totally screwed, without any hope of improving the situation. <br><br>I tried in times past to propose a subset of regex patterns that would still leave us with fast<br>
pattern matching....<br><br>murf<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
/O<br>
</font><div><div></div><div class="h5">--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>