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.
