[asterisk-dev] New wildcards for pattern matching

[Steve Murphy]

On Thu, Feb 25, 2010 at 7:03 AM, Klaus Darilion <
klaus.mailinglists at pernau.at> wrote:

>
>
> Am 25.02.2010 14:53, schrieb Pavel Troller:
> > Hi!
> >
> >> _XXX! in overlap mode:
> >>
> >> 1 is received ... wait for more
> >> 1 is received ... wait for more
> >> 1 is received ... trigger ->  dialed number: 111
> >>
> >> _XX. in overlap mode:
> >>
> >> 1 is received ... wait for more
> >> 1 is received ... wait for more
> >> 1 is received ... trigger ->  dialed number: 111
> >
> > It's not true.
> > I've made an example on a live system for you.
> > Please look at the following:
> >
> > exten =>  _133X.,1,NoOp(Collected number: ${EXTEN})
> > exten =>  _133X.,n,Milliwatt()
> >
> > exten =>  _134XX!,1,NoOp(Collected number: ${EXTEN})
> > exten =>  _134XX!,n,Milliwatt()
> >
> > Asterisk log:
> > Case 1:
> >      -- Accepting overlap call from '11442' to '<unspecified>' on channel
> 0/19, span 1
> >      -- Starting simple switch on 'DAHDI/g1-1'
> >      -- Executing [1333333333 at default-ovlp:1] NoOp("DAHDI/g1-1",
> "Collected number: 1333333333") in new stack
> >      -- Executing [1333333333 at default-ovlp:2] Milliwatt("DAHDI/g1-1",
> "") in new stack
> > Case 2:
> >      -- Accepting overlap call from '11442' to '<unspecified>' on channel
> 0/19, span 1
> >      -- Starting simple switch on 'DAHDI/g1-1'
> >      -- Executing [13444 at default-ovlp:1] NoOp("DAHDI/g1-1", "Collected
> number: 13444") in new stack
> >      -- Executing [13444 at default-ovlp:2] Milliwatt("DAHDI/g1-1", "") in
> new stack
> >
> > Both the cases were dialled the same way: A call was received over PRI
> (no SS7)
> > in overlap mode (you can see) and then, once per second, a digit has bee
> sent
> > maximum 10 times. In the first case, after 10 digits the dialling was
> stopped,
> > and after a timeout about 5 seconds the call was connected. In the second
> > example, immediately after receiving the fifth digit, the connection was
> > established, so it was not possible to send more digits.
> >
> > Do you see the diffference now ?
>
> Yes, I see. You are right. ! stops the overlap timer.
>
> So, ! and . are not only different in 2 ways - minimum number of
> characters and overlap behavior.
>
> I guess the conclusion is that 2 different wildcards are needed - one
> which stops the overlap timer and one which does not stop the overlap
> timer.
>
> regards
> klaus
>
>
No, not really. Immediate end to a pattern is the immediate end of the
pattern.
! has nothing to do with with classified pattern matching, perse. It isn't a
"zero or more"
type of construct. It's a "zero" sort of construct. It's a marker for the
end of the pattern.
"Stop here and call it a day" sort of situation. So, there's no need for one
more version
of it.

But, you are right along the 'orthogonality' lines. If we are going to
supply a regex equiv
to '+', we might as well supply one for '*'. OK, I get that. BNF, regex, all
these sorts of
systems took the trouble to supply both "0 or more" and "1 or more"
constructs, even
tho the "1 or more" is just shorthand for a char match followed by "zero or
more".
(ie, X+ == XX* )

So, all that's left is to decide what characters to use for them.
* and # are definitely out. They are on phone keypads, common input.
! and . and [ and ] are out. Quote chars are out-- they imply they come in
pairs, so `,', and " are out too,
along with '{', '}', and '(' and '), and '<' and '>''. '$' will confuse
those familiar with regex. '@' is probably not a good candidate
because you'd think it would be common in urls, which might turn up sometime
in extension values.
'^' would also confuse regex familiar folks. '&' is commonly used in stuff
like dialstrings and hints.
'_' is used to start patterns. We could use it for stuff like this, but it
might confuse. '-' is out, it is
used in range notation, and could confuse. '+' would normally be considered
open game, but it turns
up in European numbers (doesn't it?) as a prefix, so that would louse things
up or confuse at least.
| seems out, used as a separator in other places. So are comma, and ; and :
and /.  \ is out.
Let's leave out ?, too, as someday we might want to use it in patterns to
match its regex
usage, a "0 or 1" of any character, or some dialplanishly appropriate set of
almost any characters.

That leaves us with ~ and %.

So, how about:   ~ at the end is 1 or more of the preceding character.
and % is 0 or more of the preceeding character. Or vice versa, as the
original
proposal was really wanting ~ for 0-or-more usage. It don't matter to me,
but
the % has those little circles in its graphics, crying "Zero!"... any
pnemonic trick helps.

Am I making sense? Have I missed something big?

murf

-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100225/7fae2506/attachment.htm