[Top] [All Lists]

Re: Action Interaction

2004-11-15 07:43:52

Jutta Degener wrote:

On Fri, Nov 05, 2004 at 11:30:26AM +0000, Alexey Melnikov wrote:
Tim Showalter wrote:
In general, I agree, and I will try to incorporate these changes into the next draft.

Alexey Melnikov wrote:
3). Need to state that "reject" and "discard" are incompatible.
They aren't clearly incompatible. If keep+discard aren't incompatible, why would reject+discard be incompatible?
Section 2.10.4 says:
Implementations SHOULD prohibit reject when used with other actions.

Right, so it depends on whether implementations implement
this SHOULD.  (With ours, it's configurable.)
Why? Why not have two separate actions instead?

I'm not sure why something other than the quoted statement is needed.

But I don't follow this logic:

As you noted below I am trying to redefine what "discard" means based on the English meaning of the word. The mailing list archive confirms that many people got confused by the definition of "discard", so maybe we should adjust its definition.

I frankly don't care either way, but this must clearly be stated. Either
a). when both discard and reject are requested, reject is executed

Apart from the SHOULD in 2.10.4 (and the application-level
considerations behind it), I don't see what the technical
problem with executing discard and reject is.

I never said there is a technical problem. I am just trying to use the usual meaning of the words.

 Discard cancels
the implicit keep.  Reject sends a nastygram and cancels the implicit
keep.  So, discard + reject do the same as reject alone, just
like discard + fileinto do the same as fileinto alone.

Not because someone explicitly said so; the math just works
out that way.
b). the last one of discard/reject is executed (i.e. discard also cancels a previous reject)
No!  Please, no time travel.
There is no time travel for implementation that execute all actions after the script interpretation, as opposed to executing an action at the time of interpretation.
But I am Ok with not requiring this.

c). discard and reject are incompatible (as discard is a silent reject and one can't reject silently and not silently at the same time).

That would be the right thing to do for implementations that
implement the SHOULD in 2.10.4.  (Not because "discard is a
silent reject"; it isn't, although that may be the way some
people chose to think about it.)

The normal *user* idea of "discard;" is usually better
expressed by "discard; stop;" -- don't file it, and don't
do anything else with it, either, because after something
is discarded (in the English sense of the term), it is gone.
But that's not how the sieve discard action is defined--it
just cancels the implicit keep.
I don't really like that there is a choice between a) and c). Can we just pick one? There is already too much optional stuff in Sieve.


<Prev in Thread] Current Thread [Next in Thread>