On Thu, Oct 20, 2005 at 03:58:35PM -0400, Mark E. Mallett wrote:
On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
Section 4.7: "A script will fail if it attempts to execute two or more
vacation actions."
Should "will" be either SHOULD or MUST? "will" describes an
implementation
behavior.
I also had a comment on 4.7 that I sent off-list. Essentially:
I did wonder about that wording; seems to me that the the script as
a whole probably shouldn't fail, but the non-first vacation
action(s) should give an error. i.e. duplication vacation actions
should fail, not abort the entire script. (Not to mention that if
the script were to fail on the second "vacation" then there would be
no need to say "or more".)
The base spec says:
When an error occurs in a Sieve script, all processing stops.
So either you ignore vacation actions starting at the second one, or
you generate an error. If an error is generated, all processing stops.
If so, indeed there can't be a third.
I'd say, let's include an example showing two vacation actions and
a fileinto afterwards, stating the fileinto can not happen (assuming
the second vacation action does generate an error), but:
I see no reason to have such an example.
Does the base spec allow action execution reordering?
There's no prohibition against it, so the answer would apppear to be "yes". The
base spec does go so far as to say that you can perform actions as you go or
wait until evaluation is complete and then perform them all.
That's not as crazy as it sounds.
IMO it doesn't sound crazy at all.
Of course actions with side effects
must not be reordered, that goes without saying. And how about actions
without side effects?
fileinto "a";
fileinto "b";
If a message is filed to "b", will there be one in "a", or could
both actions be processed simultaneous after the script ran, "a"
fails with a runtime error and "b" suceeds?
Sure, that's possible. Or you could have a situation where "a" is over quota
but "b" is not. And what about transient quota errors? Suppose "a" is over
quota but still within it's "grace period" where messages are queued rather
than bounced. So the message to "a" sits in a queue somewhere but "b" sails
through.
Implementations have to deal with all of these issues and many more. Actual
delivery to the folder may be deferred until long after the script has
executed, making it effectively impossible to convert a delivery failure into a
script failure. And even if it is possible for fileinto, it isn't for
redirect, as you point out below.
I expect that
redirect "a(_at_)nosuchdomain";
redirect "user(_at_)example(_dot_)com";
may well send a message to "user(_at_)example(_dot_)com", despite the first
causing a run-time error, because the action sets up the delivery of
the message, but does not deliver it on its own. But strictly
speaking, this _is_ action reordering. We need to say something about
this topic.
I disagree. I don't think we have to discuss each and every thing we
don't prohibit.
In case the second vacation causes an error: How would an example
for that look like?
While thinking about it: The base spec does not define if anyof and
allof perform shortcut/lazy evaluation. After all the years, all we can
probably do is saying that depends on the implementation. It should be
mentioned, because it may cause the same script to behave different on
different implementations.
It is mentioned to the extent that the spec says short circuit evaluation
is encouraged. I remain to be convinced that more is better here.
Ned