On Wed, Sep 10, 2008 at 02:03:42AM +0200, Stephan Bosch wrote:
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.
That one was my note. My problem was mainly that, according to the
version of the draft I was commenting on, the capability would only be
enabled inside of a block where an 'ihave' test had contributed to a
conditional evaluating to true. I thought it would be difficult to
coordinate the truth of the conditional evaluation, which might contain
a lot more than just an 'ihave', and the enabling of the capability.
(it's more than that, read the text at the link I guess, even though I
didn't elaborate at length I tried to present the gist of the problem.
I also would have prefered to have explicit enable/disable of the
capability, distinct from the test, but the way it evolved is ok).
This has been addressed in the later 'ihave' drafts by having it say
that a capability is enabled when a ihave test successfully operates on
that capability, given that an earlier definition says that an ihave
test is successful when all of the capabilities given to it are
available.
Anyway, I think that was quite a bit different from what you are
saying here:
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 [...]
And yeah, that can present some difficulties. But I think as long as
you know what the lexical elements of a test or an action are and how
each one is terminated, or the syntax of a comparator token, it's
possible to find a way to swallow an unknown element such as action,
test, comparator name, etc., and generate code with enough information
that it can resonably report an error at runtime should it be
encountered. I'm looking forward to doing this myself :)
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.
FWIW, my implementation actually supports #ifdef-like constructs that
can be used to enable or disable code based on various capabilities;
I rather like putting that level of control at, well, that level, but
obviously one can't mandate that everyone implement things that way.
mm