Re: Standard to selectively disable rules in sieve script?

[Kjetil Torgrim Homme <kjetilho@xxxxxxxxxx>]

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.