Re: Exposing global (default) sieve script through Managesieve

On 6/3/2012 10:57 PM, Matthijs Kooijman wrote:
>
> The copy-on-write scheme I describe above may solve this, as it
> remembers (somehow) the status of the account: either an
> untouched/unconfigured account or an account with no active scripts.
> This behavior could be combined with the solution you describe above.
> Yeah, the copy-on-write approach is probably a good idea.
>
> A downside of the copy-on-write approach is that if you change the
> global script later on, it doesn't affect users that made any changes to
> their sieve configuration (as opposed to my proposal, where only changes
> to the actual "default" script would prevent this). However, I
> mentioning this just for completeness, since I don't really think this
> is much of a problem.
>
> Also, the "no sieve configured" case could be detected by the existence
> of a sieve_directory, perhaps?

Something like that, yes.

>> In my last release of Pigeonhole I added support for putting scripts
>> inside a dict database (or any other storage facility once implemented).
>> Support for ManageSieve accessing such alternative data stores is
>> lacking still, but, once I implement that, I also intend to address the
>> issue you describe here. I'm probably going to structure it very similar
>> to Dovecot's own mail storage library, meaning that plugins can override
>> certain aspects of the storage's behavior.  This should allow for all
>> kinds of magic in the script storage, including what you describe above.
> Would it make sense to implement such magic inside the script storage,
> or on top of it? The latter means the magic will work for every storage
> implemented, which would be an advantage?

Definitely on top.

Regards,

Stephan.