Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> 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