ietf-mta-filters
[Top] [All Lists]

Re: variables draft (draft-homme-sieve-variables-00.txt)

2003-04-08 11:30:27

On Tue, Apr 08, 2003 at 10:23:11AM -0700, 
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
the match order for [ a, b ] [ A, B ] should be aA, bA, aB, bB.  this
means that messages sent to both addresses will be forwarded to
<kjetilho+foo(_at_)ifi(_dot_)uio(_dot_)no>, i.e. the first match string has 
precedence.
in this example, what the wildcard matches is irrelevant.

Cute. I can live with it.

I'm not happy.  Before this, I could stop matching when any combination
matched.  Now I have to either keep reading to the end just in case a
variable assignment changes, or figure out in advance whether any of
the strings following use any variables and keep reading to the end only
if that is true.

By the way, coupling variable assignments and matches _really_ makes
life interesting for anyone implementing streaming matches such as "body".

Without them, it's possible to at least predict a finite number of
possible variable values and match those in parallel in one pass.

With variables, you may not be able to predict what string a later
match will match against, because the match pattern itself may contain
variables that are set as the result of previous match patterns.

        if body :matches "*call(*,*)*",
        {
                if body :matches "*response(${3},${2})*"
                {
                        ...
                }
        }

These are extreme examples that don't affect the ability to parallelize
the more common fixed choices, but I'm not looking forward to the
extra complexity, and I don't think it's justified by functional
benefits.

Jutta

<Prev in Thread] Current Thread [Next in Thread>