On Tue, 2006-07-11 at 16:28 +0100, Dave Cridland wrote:
But I think this is really needed.
Otherwise, you're telling users to write their Sieve filters in a
manner which is beneficial for optimization on the server. This ain't
gonna happen, as they say.
possibly not, but how do you suggest the server should handle it?
flatly ignore all tests which require unavailable information? if so,
if a user writes a script with lots of explicit tests and an
unconditional "reject" at the end, you get disaster.
one other option is to make it explicit with different scripts for the
two situations.
Your suggestion means that for best performance, a very careful
choice of Sieve generator and server implementation is required. Bear
in mind that one of the more common Sieve generators is the user - I
know plenty of sysadmins who'd argue for more choice in their users,
but I can't see this happening.
I just checked the numbers at our site, and of our 62804 users, 3156
have installed Sieve filters. 31 of these are handwritten, the rest are
generated by avelsieve (Squirrelmail plugin). I convinced it's possible
to write a good UI which promotes putting envelope tests at the top.
Whilst your proposal is certainly
bending the rules less, I don't think it's providing any benefit
aside from purism.
I don't see it as purism as much as correctness and determinism :-)
To put it another way, I'm perfectly happy for some actions to have
an implicit stop as a side-effect. In fact, until I skimmed this
thread, I sort of assumed that reject *did* have an implicit stop -
maybe it just sounds like a final decision.
I don't disagree with this, a quite common error for our users is to
omit the "stop" after the "fileinto", so they get several copies of some
messages. it's much too late to change fileinto/keep/etc now, though.
--
Kjetil T.