At 4:34 PM -0500 1/19/99, Lawrence Greenfield wrote:
In the implementation of sieve for Cyrus that I'm working on, I'm
following the following convention:
Running a script accumulates a list of actions to take.
Upon successful termination of the script, ALL actions are taken.
Currently, this allows unlimited fileinto's and forward's.
Not all implementations will be able to support multiple fileinto
actions. It depends on the environment. I suggest we state that
only the last fileinto is acted on, and create a new optional action
for copyinto.
(We could make the first fileinto the active one, but I think the
last one is much more intuitive. And while it is true that some
users may put high-priority filters first, there is no requirement or
even convention to do so. Also, a high-priority filter can always
include a stop action.)
If no actions have been accumulated by script termination, a keep is
performed.
If an action conflicts with an action already on the list, there's a
run-time error. That is, if a "keep" has been specified and then we
come across "reject", that's an error. "reject" and "discard"
conflict with all other actions (and each other). "fileinto",
"forward", and "keep" can all be performed together.
Are keep and reject exclusive, or does the last one simply override
the first? It really is a question as to the semantics of keep.
Since this is the default action, what is the purpose of an explicit
keep? It can be either to server as protection against a subsequent
reject, or it could simply be a way to explicitly state (and
document) the default action. I can see an argument for both choices.
If any run-time errors occur, a "keep" is performed.
---
I think this is a logical collection of rules. Site policies may want
to limit the number of forwards or fileintos done.
Yes, but Sieve should not itself impose a limit, such as only one forward.