Cyrus Sieve futures

[Ken Murchison]

I wouldn't think so.  The deprecated actions would still have their 
existing bytcodes, and I'd add a new bytecode for the enotify flavor of 
notify.


On 02/06/2017 05:40 PM, ellie timoney via Cyrus-devel wrote:
> Is that going to conflict with this?
> https://github.com/cyrusimap/cyrus-imapd/issues/1778
>
> On Tue, Feb 7, 2017, at 09:34 AM, Ken Murchison via Cyrus-devel wrote:
>> All,
>>
>> I'm in the process of rewriting the Sieve parser and adding new
>> extensions for what will become part of Cyrus v3.1.  We currently
>> support deprecated and non-standardized extensions "imapflags"
>> (standardized as "imap4flags) and "notify" (standardized as "enotify").
>> I'd like to rip out the parser and bytecode generator for these
>> extensions, and leave just the bytecode executing code for the
>> deprecated actions "mark", "unmark", and "denotify".
>>
>> Any existing scripts using these actions (or the older "notify" syntax)
>> would continue to run.  New/updated scripts would have to switch to
>> using the updated "notify" syntax and replace "mark" and "unmark" with
>> "setflag"/"addflag" and "removeflag".  Does anyone have an issue with
>> these changes?
>>
>> Does anyone have any requests for standard extensions that we don't
>> currently support?  Note that "variables", "mailbox" and "*metadata"
>> will be in Cyrus 3.0 and "ereject", "editheader", and "extlists" are
>> already in what will be the 3.1 branch.
>>
>> Extensions that I'm looking at implementing (pretty much because they
>> are low-hanging fruit) are "duplicate", "environment", and "ihave".  I
>> may also look at "replace" and "extracttext" which would be useful if we
>> add handling of calendar events to Sieve.
>>
>> -- 
>>
>> Kenneth Murchison
>> Principal Systems Software Engineer
>> Carnegie Mellon University
>>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University