ietf-mta-filters
[Top] [All Lists]

Re: Extension mechanism/support

1998-01-20 20:40:43
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
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?

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.

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

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.

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
}

Refer to Ned's example on Postscript -- this encourages "portability" which
seems less than likely to actually be portable.

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.

A "spam dumper service" can be handled; some sort of #include directive is
probably needed (so you can get the most up-to-date filter); this script
simply has to get processed in the same way, and the server has to support
the extensions the script requires.

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.

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.

-- 
                                          Tim Showalter 
tjs+(_at_)andrew(_dot_)cmu(_dot_)edu