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.
I like this way of doing it. The "want" business used in an earlier example
didn't feel right, but this does.
There is precedent for this sort of thing, BTW. PostScript has the ability to
check for support for various extensions and only use them if they're
supported. (Or alternately, provide a different way to do something.) This
functionality used to be used a fair amount, although I haven't seen much of it
recently.
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.
Yes, although this does have a negative aspect - an upgrade changes behavior
and actives old code someone forgot was even there. This issue would certainly
need to be discussed in any specification we write.
> 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.
Well, there has been talk about having some way in managesieve to get the list
of supported extensions, but AFAIK it has never made it into an actual
specification. Of course this may be more a result of no work having been done
on managesieve recently than anything else.
> 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".
Er, no. The base specification leaves this open. Implementations are free to
perform as much checking as they want before executing a script. It is
perfectly permissible to check and make sure that the script doesn't reference
any tests or actions that aren't listed in the require clause. Our
implementation does this, as a matter of fact.
The way we'd probably change this is to see if environment is listed in the
require clause, and if it is disable this sort of checking. There's already a
way to disable this sort of strict checking, so this won't be hard for us to
implement.
I note in passing that only new tests, actions and comparators are amenable.
to this sort of thing. Something like
if environment "extensions" "variables" ...
makes my head hurt.
Ned