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

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

2003-04-07 19:18:14

[Ned Freed]:

  [Lawrence Greenfield]:
  > can no longer short circut due to:
  >
  > "The decimal value of the numeric variable name will index the list of
  > matching strings from the each of the group operators in the latest
  > regular expression match."
  
  I don't think that was the intent, and if it was, I think it
  should be changed. I read "latest" as meaning "the latest
  operation that was performed.

yes.  I've changed it to "most recently evaluated match".

  Big mistake IMO. Short circuit rules should still apply. The base
  specification recommends short circuit evaluation of lists. This
  should be changed to a requirement when variables are in use.

short circuit is fine, but:

    if header :matches [ "To", "Cc" ] [ "coyote(_at_)*(_dot_)com", 
"*(_at_)*(_dot_)com" ] {
         ...
    }

which tests are done first?  if we care about effiency, it is best to
do all tests against the same match expression first.

   "To" :matches "coyote(_at_)*(_dot_)com"
   "Cc" :matches "coyote(_at_)*(_dot_)com"
   "To" :matches "*(_at_)*(_dot_)com"
   "Cc" :matches "*(_at_)*(_dot_)com"

this seems intuitively correct, since the first list contains
"synonomous" headers for the purpose of the match.  it also gives
natural precedence to the order of the match strings (most important
first).

  > Modifiers should be omitted from this specification. These are
  > functions; if we're going to define functions, fine. If not, fine.
  
  I have no problem with this approach either.

since folder names are case sensitive, a method for normalising input
into all lower case or similar is highly desirable.

  Given that variable names are explicitly limited to ASCII
  alphanumeric I fail to see an issue on this point. As for scope, I
  think global scope is the right, and indeed the only realistic,
  choice.

if the need ever arises, we can define a action (say, "LOCAL") to set
variables with block scope.  I don't intend to turn Sieve into a
general purpose programming language, so I'll leave it out for now :-)

-- 
Kjetil T.