official dev team position regarding multiple times requested feature (global sieve)

[Jeroen van Meeuwen]

On Tuesday, July 24, 2012 11:30:20 AM mailing list subscriber wrote:

Dear mailing list subscriber,

Apologies for taking as long as I did to get back to this.

> On Tue, Jul 24, 2012 at 10:59 AM, Jeroen van Meeuwen (Kolab Systems)
> <vanmeeuwen at kolabsys.com> wrote:
> > I'm curious to learn what exactly would be the set of requirements that
> > would enable a mandatory Sieve script feature to be integrated into Cyrus
> > IMAP;
> > 
> > - Would setting a mandatory script implicitly disallow users to write
> > additional(?), new scripts?
> 
> no
> 
> > Would this be Yet Another Setting?
> 
> yes
> 

Let me summarize what is then the idea, if I understand correctly:

- A setting will control what script is mandatory, globally, if any, for 
example:

	sieve_mandatory_script: /path/to/sieve/script

- A setting will control whether or not the users themselves are allowed to 
write additional, new scripts, for example:

	sieve_mandatory_notexclusive: boolean

> > Would Cyrus
> > IMAP magically adjust any user-uploaded scripts to conform with the
> > mandatory script policy?
> 
> no
> 
> > - Would a script (if it were read-only for the user) read settings from a
> > location not Cyrus IMAP, such as the proverbial boolean "Yes I am
> > out-of-office" and/or "my vacation lasts until $x"?
> 
> no
> 

Where would the mandatory, read-only, invisible sieve script get vacation/out-
of-office/spam settings from, then?

> > - How many Sieve editing clients would remain compatible / could become
> > compatible with such Sieve semantics? Please allow me to shamelessly plug
> > some thoughts from Kolab[1] here, that relate to but are not entirely in
> > the same realm.
> 
> script would be completely invisible to the clients/end user. please
> see the patch in the links I have mentioned. it would just run a rule
> before the user rules kicks in, then the user bytecode would do
> whatever they want on the same message.

Right, the model that the reference listed is to have a "MASTER.siv" - which 
would be the system-controlled one, that includes other system controlled 
scripts, and includes user scripts as available/enabled/necessary.

I suppose enabling/disabling vacation is then the toggling of an include 
:global vacation.siv, prior to which (in a :personal MASTER.siv (invisible, 
read-only) included :personal vacation.siv?) settings are set? How would we 
treat the client's expectation of marking as the active scripts, any of the 
scripts that are visible?

I'm sorry, but I'm having a hard time modeling this so that we add option 
value rather than take any away, while I'm trying to map this to some model 
that would not invalidate Sieve client compatibility.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120730/e2abcf83/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120730/e2abcf83/attachment.bin