[Top] [All Lists]

Re: [sieve] SIEVE WG Status

2011-06-20 20:25:26

On 6/20/2011 5:07 PM, Cyrus Daboo wrote:
Next question: does anyone have any new SIEVE work they would like to propose at this time?

I don't think anyone can deny this WG has been successful over the years in addressing the needs of SIEVE implementations, even if at our own, sometimes slow, pace. Shutting it down now would not be unreasonable, but I think we do need to prove the utility of keeping it alive. So please chime in with your thoughts.

There is one thing I've noticed: the more user-friendly GUIs and web interfaces allow users to edit Sieve scripts as a set of intuitive (structurally pre-defined) mail filter rules. This avoids the need to learn Sieve and write detailed Sieve scripts directly, which can be daunting for the less capable mail user. However, Sieve has no real concept of a `mail filter rule', so a translation is necessary from the rules defined in the editor and the Sieve script on the server. Also, a convention is to name the mail filters to provide an indication of their purpose. Other forms of such metadata are imaginable, such as creation date, name of the creating software etc.

The problem is that such data needs to be stored somewhere. Some solutions involve storing the metadata along with the rules themselves in a database or another form of storage external to Sieve. The Sieve script is then created from this storage once the rules change. On the one hand, this avoids the complexity of parsing Sieve scripts to regain access to the original rules and metadata, but, on the other hand, it completely blocks using multiple different interfaces for editing the same Sieve scripts. Direct changes to the Sieve scripts would simply be lost once the rules change.

Alternatively, some script generators encode such metadata in Sieve comments and parse the Sieve script itself to extract the rules. This way, the Sieve script itself is the only means of storage, theoretically allowing multiple distinct Sieve generators (GUIs and web interfaces) to inter-operate with the same Sieve scripts. Unfortunately, I've seen little or no coordination between the script generator authors, which probably means that scripts generated by one interface cannot be edited through an alternative one, mostly because the encoded comments are going to be incompatible. Of course, the Sieve code itself can also be incompatible if the Sieve generators don't support the same set of Sieve features or if some code structure is not recognized. However, I think this could be mended quite easily by presenting rules that cannot be handled by the GUI itself as custom or external; not to be touched by that particular interface.

The main requirement would be that individual rules in the script can be annotated with a name and that a parsing GUI can distinguish where rules begin and end. A standardized means to achieve this could, in my opinion, increase interoperability between Sieve script generators.

However, I have only implemented a Sieve interpreter so far (which obviously doesn't care about metadata encoded in comments) and I therefore have no experience with Sieve GUIs and web interfaces and the complexities involved. I haven't seen much discussion about this subject and I am wondering whether this is currently perceived as a concern at all. I vaguely remember a short discussion about this in a thread related to Sieve in XML, but nothing else.

Are users expected to use only one interface/method for editing their (active) scripts? Would it be useful to provide a specification on how to encode meta-data in Sieve script comments?



sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>