Alexey Melnikov wrote:
> This message officially starts the Sieve Working Group Last Call for the
> following document:
>
> SIEVE Email Filtering: Ihave Extension
> <http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-02.txt>
>
> 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.
http://www.imc.org/ietf-mta-filters/mail-archive/msg03315.html), but to
my knowledge it was never discussed further.
Ihave no longer tracks with block scope so this is no longer an issue. The way
it works now is one ihave has turned on a feature it stays on.
I've built a compiler that compiles Sieve scripts into a byte code
representation.
That's how our implementation works as well. The only issue that came up while
implementing ihave was that we needed to turn off a bunch of checks the
compiler was doing - you cannot assume an extension won't change the minimum
or maximum number of arguments, or allow some additional tagged argument, or
other stuff along those lines.
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.
That's perfectly permissible, but an alternative is to do the ihave check at
compile time. THe prohibition on variables in ihave arguments makes it possible
to perform the check at compile time and reduce the ihave test to a constant
false if the extension doesn't exist and an activation of the extension and
a constant true if the extension is supported.
I would have done it your way if there was a case where we couldn't determine
the availability of an extension at compile time, but we don't have any of
those.
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.
Not necessarily. Additional tests, actions, arguments, and so on can be added
bu the grammar never changes. So you can always parse the script and, in the
case of an unknown element, simply compile it into something that signals an
error if the execution path ever gets to that point.
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.
No, such knowledge is not required. See above.
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.
I agree that this is difficult. The good news is that it isn't necessary.
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).
Cleaner, more compact scripts, for one thing. I also didn't like the idea of
introducing a new control element when it wasn't necessary.
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";
}
keep;
Sure, this is one way to do it. But it is less flexible, more verbose, and IMO
less clear. And I don't think it assists implementations nearly as much as you
seem to think. In fact in our implementation it wouldn't have been one iota
easier to implement.
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).
And else clause are going to be very common because most of the time you can't
just not do something, you have to do something else instead. So now you either
have to reuse else or invent some other control for this purpose - another
reason why tests are better.
Ned