Subject: Re: Extension mechanism/support

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

Tim Showalter <[email-masked]> writes:

>> From: "Stan Bailes" <[email-masked]>
>>
>> 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

---

From: Tim Showalter <[email-masked]>
Date: 20 Jan 1998 22:45:14 -0500

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

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

> } else if support "white-magic" {

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

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

> 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 [email-masked]

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 28 Jan 1998 17:17:56 -0500

>as with a "spam dumper" service....

perhaps I am misquoting the problems, but I know that one of the
problems that was discussed dealt with extensions that had parameters
and how to handle new parameter types.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/