Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
I guess the scenario that I'm thinking of is where a user has
same filter script both at home and at work.
The problem arises only when you read the message on a different server
at home. A simple extension list solves this problem by making your
script not run.
That doesn't solve my problem -- I *want* the script to run, remember?
Having C-preprocessor-like functionality with support so that
unsupported extensions get skipped is likely only if you want to
run the exact same script at home and at work. I can't figure out why
you want to do this.
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.
Let me try another example: Suppose that it's 1999, and there are
two major commercial implementations of Sieve in the world: BigCo's
and GoodCo's. Now, BigCo has implemented the 'black-magic'
extension, and GoodCo has implemented the 'white-magic' extension,
which has the same behavior as the 'black-magic' extension, except
they used forward slashes instead of backwards slashes (or slashes
instead of dots, whatever).
Now, if the language implemented 'support' and syntax extensions as
we've been discussing, then I could write a tool that generated Sieve
code as follows:
if support "black-magic" {
black-magic;
} else if support "white-magic" {
white-magic;
} else {
// remainder of script
}
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....
In general, if you ever expect to write a Sieve script for any other
than a single pre-designated server, 'support' is essential. I
can't see why you would want to hinder interoperability by removing
the one feature designed to "support" it.
Maybe I'm missing something: What is the difficulty you see with 'support'?
Stan