On Wed, 2008-03-26 at 15:58 -0700, Aaron Stone wrote:
Most of the Sieve clients don't actually parse the Sieve rulesets,
unfortunately. They tend to do what Avelsieve does, which is to leave
itself a comment in a particular format (for Avelsieve, it's a
serialized PHP array) so that it knows what the next block of code does.
This does indeed limit interoperability of clients.
If the clients did all parse the Sieve itself, and could edit each
other's rules using their respective gui's, then actually I think we
would need some agreement on how to mark a rule inactive (so that it
could be left in the script and turned back on by another client
without having to re-create it). It's a good point, though I don't
have a good answer myself.
agreed. reconstructing the semantics of the rules is a challenge, e.g,
consider a UI where there's a simple rule for matching mailing lists.
this would probably be a macro with lots of heuristics, checking List-Id
but also Sender and stuff like that. when loaded into a different
client it should of course handle this, but it may present the rule as a
sequence of tests rather than a single macro. IMHO, it's not realistic
to standardise these things, since we will never catch all the
use-cases.
for the case of temporarily disabling a rule, I think the most obvious
method is a simple
if false { }
around the block. that construct can hardly be used for anything else.
using comments is bad, since comments should be truly freeform and
without meaning.
--
Kjetil T.