| I'm not particularly happy with the way required works out, but it may be
| needed; all Internet protocols are required to have an extension mechanism.
|
| I'd like to drop require and rely on support.
Well, sieve is a language rather than a protocol... There's no way
to negotiate what features are supported, without introducing something
like a preprocessor (#ifdef FEATURE_X...) and that's not a particularly
attractive way to do it.
Any protocol that used sieve to describe filters would have to be
extensible, of course. For example, if IMAP or ACAP or whatever were
extended to allow a user to set up filters, then the client could
attempt to pass a filter that used a certain feature.. A server that
didn't understand that feature might return with a parse error. If
the parse error were specific enough, the client could restate the
filter without using that feature if possible. This could be automated
so that human intervention isn't required.
If you keep "require", and make it processed at parse time, and then
make some standard way for a server to report require failures, then
the client could easily use extensions if they are there, and fall back
to more basic constructs if they're not. So, it's extensible.
Or, you could drop "require" from the language itself, and rely on
something like it being present in whatever protocol is used to pass
filters back and forth.
Either that have some standard way of describing revisions of
sieve. Then the server could just tell the client what revision it
supports, and the client could form the text accordingly.
So I don't think the sieve language itself needs to support an
extension mechanism, necessarily.
--
Paul Falstad Software.com, Inc.
paul(_dot_)falstad(_at_)software(_dot_)com 805-957-1790 x520
http://www.ttinet.com/pjf/ http://www.software.com/