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.
Aaron
On Mar 26, 2008, at 2:45 PM, Patrick Ben Koetter wrote:
I've been reading the RFCs and couldn't find an answer to the
following
question:
Is there a standard syntax/notation to disable a single rule/command
within a
sieve script that contains more than one rule/command?
I couldn't find anything in the RFCs, but what I found is that
everybody seems
to use comments to disable a rule. So far so good...
The bad thing seems to be that even though everybody agrees to use
comments
nobody seems to agree on one way to do it - one way all
implementations
understand.
My research indicates that interoperability among sieve script
clients is lost
when it comes to disabling rules.
A script edited by avelsieve - this is pure fiction, I didn't test
this, but
it serves to proove my point - (probably) won't work for KMail,
because KMail
is unable to recognize rules that have been disabled by avelsieve
and vice
versa.
If I am correct, then - in my eyes - this is a major drawback in
making Sieve
useful and popular.
Am I missing something?
Thanks,
p(_at_)rick
--
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung
Patrick Koetter Tel: 089 45227227
Echinger Strasse 3 Fax: 089 45227226
85386 Eching Web: http://www.state-of-mind.de
Amtsgericht München Partnerschaftsregister PR 563