Subject: Re: Extension mechanism/support

From: "Stan Bailes" <[email-masked]>
Date: Tue, 20 Jan 1998 11:44:37 -0800

Matthew Wall <[email-masked]> writes:

>However, I think it's arguable that the second proposed requirement, that
it
>parse past unknown extensions, really has to apply. In the above instance,
I
>want the whole chain to fail so I don't accidentally file away by the wrong
>set of colors or something.
>
>This appears to me, on its face, to be the simpler approach and is more
>likely to be safe in the sense that fewer unintended consequences are
likely
>to happen if the failure mode -- especially on extensions -- is simple. The
>authoring filter agent ought simply to be told 'hey, you're yucking around
>with some unknown extensions, go fix this' when a commit is attempted.

I guess the scenario that I'm thinking of is where a user has
same filter script both at home and at work.  But at work, he wants
to use the 'black-magic' extension, to deal with certain
intra-company mail.  So he puts in his script:

if (support "black_magic") then {
   black_magic;
}

Now, maybe 'support' isn't the right test to be using here, maybe I
want a 'location' test or some-such;  but the fact remains that unless
we adopt an extension syntax, there's no way the home mail server (assuming
it doesn't support the 'black-magic' extension) can run this script.

(And if we keep the language simple (no loops, substitutions, etc), then
it remains easy to verify that all unknown extensions are properly guarded
by
'if support' clauses before script execution begins.)

Stan

---

From: Tim Showalter <[email-masked]>
Date: 20 Jan 1998 17:32:16 -0500

> From: "Stan Bailes" <[email-masked]>
> Date: Tue, 20 Jan 1998 11:44:37 -0800
> 
> >However, I think it's arguable that the second proposed requirement,
> >that it parse past unknown extensions, really has to apply. In the above
> >instance, I want the whole chain to fail so I don't accidentally file
> >away by the wrong set of colors or something.
> >
> >likely to happen if the failure mode -- especially on extensions -- is
> >simple. The authoring filter agent ought simply to be told 'hey, you're
> >yucking around with some unknown extensions, go fix this' when a commit
> >is attempted.
> 
> same filter script both at home and at work.

So my question is when does this happen?  A Sieve script is run on incoming
mail *once*.  You either receive the message at home or at work, not both,
and the result is stored.

So if you read mail at home on a server at your workplace, the message has
already been filed, and there's no problem.

But if you read mail at home and at work on seperate accounts, then you
don't need the black_magic extension because you never receive
black_magic-requiring intra-company e-mail.

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.

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.

At any rate, if the client knows what extensions the server supports and
the client understands the extensions (this is a safe assumption, since the
client put them there), it can also be responsible for taking them out of
the server doesn't support them.

Alternatively, if what you want is a preprocessor, do it on the client
where the server doesn't have to haggle with extensions and support.

Tell me if this makes sense.

-- 
                                          Tim Showalter [email-masked]