On Sun, 2006-01-08 at 08:37 -0800, Ned Freed wrote:
[snip]
So I'm suggesting that the variables spec define a base namespace
(I'm suggesting "Sieve."). And I'm suggesting that the variables
spec define a variable that MUST be set ...
From a language implementation point of view, if you're going to reserve
a keyword or a namespace, do it sooner rather than later.
Since namespaces are bound to future extensions by the current variables
draft, all namespaces are effectively reserved already.
[snip]
I also think additional environmental information might be useful to
provide
to script. Indeed, I suspect that knowing, say, the name of the system
you're
running on might be even more useful to scripts than being able to
distinguish
between delivery and other places sieves are used.
I would therefore suggest an extension specifying an "environment" test as a
better approach. I suspect we can come up with half a dozen things such a
test
could operate on.
Maybe? Sieve is a "little language" and I like to think of Sieve scripts
as being these little gnomes that push my mail around. Gnomes don't
think too hard about where they are or where they're going; gnomes just
focus on what they're doing right now.
I'm sorry, but I have to disagree. Lots of people have more than one email
account and one of the goals of sieve is for a user to be able to define
something that works in multiple places. Wanting to have somewhat different
behavior depending on the environment is a fairly obvious thing to want to do,
even when all the different environments correspond to the same place in email
processing. As a specific example, i might want to have a very different
spamtest threshhold for the filter I use on my ISP account than the one I use
on my corporate account.
This isn't to say that there aren't significant barriers to script portability.
The most obvious one is the very real possibility that the set of supported
extensions is quite different in different environments. Since requires cannot
be conditionalized this forces scripts intended for multiple environments to be
written us9ing the least common denominator set of extensions, which is often
pretty unappealing.
This all gets especially nasty when you change places. The set of available
actions at delivery time is unavoidably different from the set of actions
available within an IMAP server. This is reflected in the sieve-in-IMAP draft
in various ways, including the omission of reject. So what should
require "reject";
do in such a script?
Ned