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.