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

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

2003-04-08 14:08:29

[Jutta Degener]:

  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.

okay, I see your problem.  so which match is returned should be
undefined?  that's fine with me.  if the user needs a specific
ordering, he can split the expression.

  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.

neat!

  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.

one sledgehammer is to declare that no variable expansion is performed
on match patterns.  it may seem a little arbitrary in the spec, and
indeed it can't be expressed in the grammar without _large_ changes to
it, but efficiency of implementation may trump expressiveness here.

since body isn't out as an RFC yet, an alternative approach is to
change _that_.  for instance, implementations can be allowed to refuse
searches with non-constant matching patterns.  (this can be determined
at script upload time, right?)

-- 
Kjetil T.

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