[Top] [All Lists]

Re: Sieve extensions

1998-01-15 17:09:14
I have no real problem with this, but I object to this:

A Sieve implementation MUST interpret unknown extension
tests as always returning false, and unknown actions as
no-ops returning 'Continue'.

My reasoning has to do with the inevitability of a script where users
specify some criteria for mail "to" them (say, to a known mailing list, or
to an address considered theirs) where it works out like this.

if some-random-extension-that-i-dont-support-yet-has-critical-importance
} else {

Hmm.  Yes, this is a real problem.  I don't suppose you'd prefer
that unknown extensions return 'true' instead of 'false', right?
And I can't imagine that it's acceptable to leave the result unspecified....

How about this:  define a 'support()' test, to allow scripts
to check for existence of specific extensions before trying
to invoke them.  Your above example could then be coded like:

  if support("some_random_extension") {
    if some_random_extension("some_random_argument") {
    } else {

I would still argue that the behavior of trying to execute an
unknown extension should be as I've proposed, though.

This restricts commands to never accepting things that aren't strings or
numbers.  For instance, there's no way to incorporate this into the grammar
of this "generalized extension syntax":

set foo = 5 + 5 ;

Well, no.  I really didn't intend this syntax to be quite *that*
general.  I suppose you could always do:

  set("foo", "5+5")

But that is really pretty ugly, and I don't think we're trying
to make Sieve be Turing complete via extensions, so I don't
see this "lack" as a real drawback.

This also doesn't address the size command, which takes another "atom" as
an argument.

[NEW]       test = [WSP] ATOM (string / string-list) [WSP]

The example in section 2.7 of the draft
  Example:  if size over 500K discard;
is outside of what this grammar can do.

Yes.  I have mixed feelings about this syntax, anyway.  You certainly
could achieve the same semantics with the "simpler" syntax, e.g.,

  if larger_than 500k discard;

Or, if we really want to keep the current "size" syntax, we could
complexify the grammar to support it, but this seems like an opportunity
for simplification...

I'm not really opposed to this, but I want to be very, very specific that
it is not a minor change, and that it doesn't buy you much outside of
making some trivial extensions (like vacation) easy.

I do want some form of optional arguments, but that's another discussion.

Well, it may be the same discussion, since this proposal would seem
to support optional arguments with no further effort...


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