Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
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