The problem is that when a script is written to ask "Why did I get
called?", it will have to assume that if it doesn't know, it's
because it got called by "mail delivery".
I'm dubious about the notion that there will be lots of scripts
intended to be run in a variety of different contexts that need to
test this sort of thing.
We don't (or at least I don't) know what the actual use cases are
likely to be, so I don't know whether I agree with you or not.
It is precisely because the use cases are unknown that I'm dubious
about the extent to which the feature will be useful. Designing software
in the absence of compelling use cases often results in features of
limited utility.
OTOH, environment tests serve other purposes, and the cost of another keyword
in such a test is incredibly low.
If we
provide a good way to manage multiple scripts, perhaps with an
extension to ManageSieve, it might turn out that people always want to
do different things at the different processing points, and they'll
always use separate scripts for each. In that case, no, this isn't
necessary.
Or it might be that there are common things that people will want done,
and they'll just occasionally want to test this to do something
different now and then. In that case, we need this.
My problem isn't that the various different scripts won't have tests in
common. They will. The problem is rather that the actions you'll want to
take will be quite different (this is almost axiomatic) and the ways the
actions will be coupled to the tests will probably vary considerably.
Anyway, as the discussion's gone since the note I'm responding to,
there seems to be agreement that this and other identifying stuff would
be useful in an "Environment" extension, or some such. Really, I
didn't think it needed to be in Variables -- just that Variables seemed
a logical place to put it. I'm happy to put it in its own extension
that defines some new test, like this (using one of the examples from
the imap-sieve draft):
require ["copy", "environment"];
if anyof (environment :is "cause" "APPEND",
environment :is "cause" "COPY") {
if environment :is "mailbox" "ActionItems" {
redirect :copy "actionitems(_at_)example(_dot_)com";
}
}
Note, here, that I've used two "environment" items, called "cause" and
"mailbox".
Mailbox is a good one I hadn't thought of before. it clearly needs to be made
available. The notion of being able to distinguish between different sorts of
insertion operations is also interesting.
I agree that I like this better than doing it with variables, and it
means that if the "environment" extension is available, it can specify
the "DELIVERY" cause that I'm asking for. That satisfies everything.
I'll write up an "Environment" extension draft, if y'all think I
should. Ned? Alexey/Cyrus?
Absolutely! Why isn't it already an I-D? ;-)
I still wonder whether there ought to be a way to test for the presence
of an extension, rather than only to have the choice of *requiring* it
or not using it at all. I can see a script wanting, for example, to
send a notification IF the Notify extension is available, but not
wanting the script to FAIL if it's not.
I'm worried about this as well, but I'm not happy about the implications
of making such a change either. As Harald would say, "mumble".
Ned