[Top] [All Lists]

Re: WGLC on draft-freed-sieve-ihave-02.txt

2008-09-09 20:16:03

Alexey Melnikov wrote:
This message officially starts the Sieve Working Group Last Call for the following document:

SIEVE Email Filtering: Ihave Extension

The Working Group Last Call for this document starts on September 8th and will end on September 22nd.

I just scanned though this draft specification and, although I like the potential of this new Sieve feature, I am very worried about the implementation of all this. The issue described here was already coined in November of 2006 (e.g., but to my knowledge it was never discussed further.

I've built a compiler that compiles Sieve scripts into a byte code representation. I'd like to see this ihave feature work for my implementation even when the compiler is completely oblivious of the extensions listed by the ihave test. Given the fact that most extensions introduce new language elements, the compiler must have some means of ignoring/discarding the regions of the script that need the obscure extensions. Alternatively, doing the actual ihave test at runtime requires that the compiler can distinguish between erroneous language features and features that would have been introduced by the unknown extension (in order to produce compile time errors or runtime errors respectively). This would require knowledge about that obscure extension.

As the document itself indicates, it will be very difficult to 'parse around' the script regions that depend on the obscure extensions listed by ihave for two reasons: ihave is a test that can be arbitrarily combined with other tests using allof/anyof and the extensions activated by ihave remain active even after the block of the (els)if command has ended. Now I am wondering why this choice was made. What is the benefit of being able to write complex conditional expressions with the ihave test and why not 'scope' the use of the extension within the block it controls? (Note that these issues are somewhat interdependent).

Both of these problems could for instance be mitigated by introducing ihave as a control structure instead of a test command, e.g.:

require "ihave";

redirect "copy(_at_)example(_dot_)com";

ihave "fileinto" {
        fileinto "INBOX.folder";


Here, the use of the fileinto extension is scoped within the block controlled by the ihave command and it is invalid outside that block. If the compiler is completely oblivious of the fileinto extension it can now safely discard the ihave command and implicitly be rid of all script regions (in this case the block containing the fileinto command) that depend on the unknown extension. It thus becomes similar to C's #ifdef for Sieve compilers that handle ihave at compile time.

The only thing the above sample script omits is a form of 'else' case to execute when one of the listed extensions is missing. Other solutions are of course imaginable (more are listed in the posting referenced above).


Stephan Bosch