On Wed, 2004-05-26 at 20:20, Timo Sirainen wrote:
On 27.5.2004, at 02:31, Geo Carncross wrote:
I've thought about something similiar before, but I've mostly just thought about performance and complexity issues with it. Creating a single view from many mailboxes could be slow without some special indexing.
It shouldn't be slower than performing the actions manually.
Sure, it's not, but clients aren't doing this manually now. Doing it in a simple way would be easy I guess, but I'm not sure if the performance would be good enough to be acceptable.. Especially if a view consists of tens of mailboxes. Each synchronization would require scanning through changes in all of them.
Perhaps another way would be to maintain separate indexes for each view and (see below).
I had been thinking about making some global index about mailboxes and their states. So that by just reading one file would be able to tell what mailboxes have changed. With that kind of system it would work much better.
This would be easier still with an LDA that could pull a trigger when a mailbox needs re-syncing. One could enable a configuration option called (say) lda_trigger = that would refer to a spec identifying a pipe (possibly per mailbox) that dovecot could select() on. any writes to it would fill the buffer and cause dovecot to rescan.
If dovecot wasn't watching the pipe, and the pipe buffer got full, "oh well", dovecot should expunge the pipe buffer when it starts up anyway. the LDA trigger-pull could be as simple as:
|echo '' > mailbox/lda_trigger 2>/dev/null; exit 0
being added to ones .qmail file. Similarly, .forwards could be altered similarly.
This watching of a pipe could solve other problems (like avoiding extra stat() calls)