Subject: Re: Extension mechanism/support

From: "Stan Bailes" <[email-masked]>
Date: Tue, 20 Jan 1998 10:32:14 -0800

Tim Showalter <[email-masked]> writes:

>Recent opinion seems to indicate that
>(1) support is not useful, and
>(2) that a list of required extensions should be stated at the top of a
>    script.
>
>I believe that I should
>(a) remove support from the draft
>(b) replace it with some syntax that puts the extensions in some other (as
>    yet undefined) form.
>
>I like this, and I'd like to move forward with it if we have consensus on
>it.
>
>If this is not the case, please speak up.  (If it is the case, please wait
>until everyone agrees and we can move on to figuring out what (b) means.)

Well, I don't like this.  Here's why:

The real issue here is interoperability.  If interoperability of Sieve
scripts isn't necessary (i.e., you'll only every run the script on the
MDA for which it was designed), then a simple list of required extensions
at the top is fine, and you don't need a generalized 'support' test.

However, if users might want to run the same Sieve scripts on multiple
servers (home and work, say), then interoperability *is* a requirement.
I believe interoperability, so defined, should be a requirement.

This has, as far as I can see, two implications:

1. It must be possible to test for the presence of an extension
2. It must be possible to parse past 'unknown' extensions.

The best proposal to support '1' is the 'support' test defined in 5.8.
The only proposal so far which supports '2' is my suggestion on this
list Jan 15.

Further, I *do not* want to see Sieve turn into YAL, and I am opposed to
any efforts to add features such as variables, loops, closures, etc.
to Sieve.   The Sieve charter should specifically restrict the core
language to simple match/action rules, and if a site or implementation
wants to do anything fancy, a "real" programming language should be
used, and bound to the Sieve script using the "extension syntax".

Stan

---

From: "Matthew Wall" <[email-masked]>
Date: Tue, 20 Jan 1998 14:10:34 -0500

> 2. It must be possible to parse past 'unknown' extensions.

Stan's post brings to mind another consideration: some extensions may
themselves require extensions in order to function correctly. For instance,
an auto-file-by-favorite-color-of-sender extension may require the
ordered-list-of-favorite-colors extension.

You thus certainly have to have a test for the presence of an extension in
this case. 

However, I think it's arguable that the second proposed requirement, that it
parse past unknown extensions, really has to apply. In the above instance, I
want the whole chain to fail so I don't accidentally file away by the wrong
set of colors or something.

This appears to me, on its face, to be the simpler approach and is more
likely to be safe in the sense that fewer unintended consequences are likely
to happen if the failure mode -- especially on extensions -- is simple. The
authoring filter agent ought simply to be told 'hey, you're yucking around
with some unknown extensions, go fix this' when a commit is attempted.

(And here Matt pauses to think of some disastrous FLAMES misfiling
episodes...ugh.)

- Matt

---

From: "Stan Bailes" <[email-masked]>
Date: Wed, 21 Jan 1998 11:22:10 -0800

Tim Showalter <[email-masked]> writes:

>> From: "Stan Bailes" <[email-masked]>
>But the extension doesn't do anything, and a reasonable client could remove
>it.  You have to have a client in the loop to submit the script; this isn't
>an unreasonable assumption.

I don't know what kind of client you have in mind.  Clearly, people
will develop whizzy clients to allow users to create filters without
having to edit Sieve text.  But we don't want to make it impossible
for people to create Sieve scripts using conventional text processing
tools (e.g., emacs)

The only "client" absolutely necessary is one which handles transport.
I wouldn't like to see us mandate a complex client.

>If the client can do it, it decreases server complexity and allows the
>clients greater flexibility in choosing corrections to extensions.  A good
>client could raise a dialog saying "black_magic is not supported on this
>server."

What server complexity are you talking about?  'support' itself? (!)

>> Because, except for the 'black-magic' bit, both scripts are really
>> the same, and it's easier to keep them in sync if I know they're
>> supposed to be identical.
>
>The existance of "support" doesn't change whether or not the scripts are
>effectively identical.  You know this regardless of what's in the spec.
>What you really want is some sort of include directive, possibly on the
>client, to include the common code.

Perhaps 'include' would be a desirable extension.  But it doesn't solve
this problem.

[snip]

>> You may suggest that the extension selection is a 'meta-language' issue,
>> and that my tool, or my UA, or someone should figure out the extension
>> compatibility matrix and only pass the correctly formed script to each
>> server.  This "works", but seems decidedly less functional than simply
>> implementing 'support', and totally fails in the case where a single
>> author is generating a script designed to be used by multiple users,
>> as with a "spam dumper" service....
>
>It is decidedly more functional.  It allows *more* flexibility, not less;
>instead of depending on the server to do the right thing, you can tell the
>server exactly what the right thing is on the client.

I think you're trying too hard here -- In terms of functionality and
expressiveness, I can implement 'require' (or whatever it's called)
using 'support'.  You can't implement 'support' using 'require'.
'support' provides strictly more functionality than 'require'.

>> In general, if you ever expect to write a Sieve script for any other
>> than a single pre-designated server, 'support' is essential.
>
>This is false.  You're assuming (a) that all scripts will use extensions to
>the language, (b) that all servers will support differing extensions, and
>that (c) users will consistantly having scripts on more than one server.
>In practice, most scripts won't need bizarre extensions, most servers will
>support the same extensions anyway, and most users will use a signle server
>and rarely change their script.

In practice, *some* scripts will use extensions, *some* servers will
support site-specific or vendor-specific extensions, and *some* users
will use more than one server, either simultaneously (home/work) or
serially (job->job->job).

>> Maybe I'm missing something:  What is the difficulty you see with
'support'?
>
>Again, see Ned's comments on Postscript.  Or read some C code where someone
>has decided to be "portable" to Unix variants with very different features.

Well, I'm not a Postscript expert.  But I am a Postscript user, and from
my perspective, Postscript implementations interoperate quite nicely.
I did a little research, reading the Postscript FAQ, and other Postscript
programming resources, and frankly, I couldn't find a word about the
"total disaster" Ned describes.  In any case, Ned's Postscript horror story
appears to have resulted from what might be described as "non-conforming"
implementations, where extensions were used without first checking for
their presence.  I believe that if we were to specify that such scripts
fail (exactly as they would were a 'require' present), we'd avoid the
whole scenario.

As for 'C'; sure, I've read code that's unreadable because of a bazillion
'#ifdef's.  But the solution isn't to abolish '#ifdef'.  Most competent
programmers have discovered how to properly encapsulate platform-specific
code, and telling them that they can't use '#ifdef' isn't going to help
them get their jobs done...

I'm not happy with this discussion.  It feels too much like a religious
debate, and not enough like a true technical analysis of the problem.
I think we're starting to reach the point of repeating ourselves, so
if anybody has a fresh insight into this, please speak up.

Stan