Michael Haardt wrote:
if environment "extensions" "notify" {
....
}
I must be missing something, but why would you want to write scripts
that way? Which application would profit from this extension?
I can imagine that a way to find out which extensions are available
is very useful for GUIs generating Sieve code, or even humans, but
for scripts?
Well, the point of Sieve is for the scripts to be portable. Ideally,
I should be able to move a script from one environment to another,
and it would still work.
But now we have to consider the meaning of "work" [or "is" (it's a US
politics joke; never mind)]. Suppose that a script was designed to
to a whole bunch of stuff, using fileinto and redirect and whatnot,
and then at the end it just wants to say, "OK, if, after all this,
the message is going into a mailbox called "important", and the
notify extension is available, then notify the recipient by pager.
If I should move that script to a system that doesn't support
notify, I might still want it to "work", in that I'd want it to do
everything except the pager bit. But if the script be coded thus:
require "environment", "fileinto", "notify"
...
[do all the useful work]
...
notify [...]
then it will fail completely when it's run somewhere that doesn't
support notify. If I have the option of coding it this way:
require "environment", "fileinto"
...
[do all the useful work]
...
if environment "extensions" "notify" {
notify [...]
}
then I get what I want, and I don't have to change the script. And if,
some say, my system adds support for notify, I'll start getting paged
without having to find out that it's been upgraded, and without having
to put the notify code back into the script.
If I used a GUI and it offers notifications, then I expect they are
available.
(1) You're ignoring the script portability issue.
(2) I would not make that assumption anyway. There's no way for a GUI
to query the Sieve system, and in a mix-and-match world there's no
reason to assume we'll have bought the Sieve engine from the same
source as we got the script builder from.
I don't think the base specification unconditionally allows dead
code blocks that contain unknown extensions, like:
if false {
unknown_extension;
}
Does the environment extension focus on the above usage and is it OK if
it enforces implementations to allow unknown extensions in dead code?
I'm not sure I understand what you mean by any of that.
I *think* you're asking whether the error is generated by the parser or
by the execution, and I believe the answer is "execution". So if
"unknown_extension" is never executed, there should be no error.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam