Subject: Re: Sieve extensions

From: "Stan Bailes" <[email-masked]>
Date: Thu, 15 Jan 1998 16:05:52 -0800

>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
> {
> keep;
> } else {
> discard;
> }

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") {
      keep;
    } else {
      discard;
    }
  }

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...

Stan

---

From: Tim Showalter <[email-masked]>
Date: 16 Jan 1998 00:12:13 -0500

> From: "Stan Bailes" <[email-masked]>
> Date: Thu, 15 Jan 1998 16:05:52 -0800
> 

No, I'd prefer that they return an error and leave the user's mail
unprocessed.  They're essentially link errors and can be detected just
after you finish parsing the script.

> How about this:  define a 'support()' test,

That'd be section 5.8 in the draft.

> unknown extension should be as I've proposed, though.

I strongly disagree.  This will result in unpredictable scripts.  Every
**typo** is processed as an unrecognized extension.

> > [re: the mystery math extension]
>

I consider ruling it out to be a serious drawback.

>   if larger_than 500k discard;

I consider larger_than to be less desireable, and in fact, a similar syntax
was removed in an earlier revision.

> to support optional arguments with no further effort...

This proposal supports varible numbers of arguments with no effort, that's
true.  I want tagged, UNIX-style flag options, or something similar.  Such
options could be used to clean up the size syntax, and could also clean up
some of the lingering worries I have with the vacation extension.

-- 
                                          Tim Showalter [email-masked]