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

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

2003-04-08 14:30:17

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.

Er, I never said that expressions shouldn't short circuit. I think they
should. But this issue, it seems to me, is independent of short circuiting.

The point here is that the saved non-wildcarded parts of the pattern can
be useful. Not that expressions must be fully evaluated. On the contrary,
if they are fully evaluated the non-wildcarded parts aren't nearly as useful.

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

Coupling variable assignmens and matches doesn't change the problem in 
any material way. How about:

   set foo "bar"
   if header :contains "to" "foo"  {set foo "bletch"}
   if body :contains "${foo}"

So as I noted previously, the addition of variables and their use in body
effectively eliminates streaming matches.

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

Yep. I plan to either preclude the use of variables and body or else
disallow variables in body arguments because of this.

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.

The functional benefits of variables are enormous -- I receive many more
requests that can be satisfied with variables than I do for the ability
to search bodies.

                                Ned

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