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

Re: some input on sieve-00

1997-04-26 10:19:25
6. Errors in Processing a Script

The stipulation that implementations SHOULD NOT try to recover from a
script with errors is a problem for me.  Aborting within an 'if' clause
makes sense to me, but to totally stop filtering if any error is encountered
is the wrong thing to do.  I would venture a guess that most users would
consider this a very bad characteristic of the mechanism.

Personally, I would like to see an 'onerror' command that would allow you
to try and trap an error.  This was actually a nice feature on one of
the basics I used in grade school many years ago, as there were some cases
where it came in useful.  

I would like to see an optimization made to the grammar.  In the elements
of an if-clause condition that use a list as an argument, I would like to
see the ability to not necessarily have the parens for single-item lists.
It might also be nice for users to not have to use quotes around words that
don't need them.

I agree on the single item lists, but not on the quotes.  The UA can
put them in, and it makes parsing a lot simpler.

Here's an abbreviated version of the example in 2.5 to illustrate:
 if any-of (header ("from")
                   contains ("bart" "homer" "smithers" "burns" "lisa"),
            header ("subject") contains ("URGENT")) then
    fileinto "INBOX"
 endif
Elimitating spurious parens:
 if any-of (header "from"
                   contains ("bart" "homer" "smithers" "burns" "lisa"),
            header "subject" contains "URGENT") then
    fileinto "INBOX"
 endif

This makes some sense to me, as the lexical meaning is still unambiguous.

Eliminating sprurious quotes:
 if any-of (header from contains (bart, homer, smithers, burns, lisa),
            header subject contains URGENT) then
    fileinto INBOX
 endif
The rule for whether or not quotes were needed would be based on avoidance
of conflicts in the grammer (eg: whitespace and commas).

I think this behaviour is more novice-friendly.

While it is novice friendly, the parsing becomes more complicated.
While it might be argued that the implementor can afford to get
complicated, I would rather see the quotes around the strings stay
there, as when I read the script without quotes, it is not immediately
obvious what the strings are and what the verbs are.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498          http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)