Updates:
On Mon, 2008-06-09 at 05:51 +0300, Timo Sirainen wrote:
I merged all the new features and latest v1.1 changes under one tree:
Nightly snapshots are also from v1.2 code tree nowadays.
- CONDSTORE extension is probably the largest change. It adds new "modification sequences" for messages that increase whenever the message's metadata changes.
I'll probably have to reimplement the way modseqs are calculated, because modseqs will be very useful when implementing replication and the current way just doesn't work with it. If modseq-supporting clients see the current modseqs and later the server gets upgraded to new modseqs, the clients will most likely break. So this change should be done for v1.2.
Modseq changes are implemented. The only issue with CONDSTORE is that STORE UNCHANGEDSINCE command doesn't atomically check-and-update. Implementing the atomicity should be pretty easy since there is a similar check already in the code. The largest issue with it is changing APIs enough to support returning back which messages failed the STORE. Still should be pretty easy.
- Virtual mailboxes should work fast after mailbox is opened. The initial opening could use several optimizations though. It could probably share some code with QRESYNC to avoid the full initial search (storing each backend's modseq to index header). Also if search parameters don't contain any dynamically changing data, there's no point in searching the old messages.
Implemented initial opening optimizations. I haven't done much testing though, other than it appears not to crash and appears to work with simple tests. :) So the current implementation should be as fast as it's possible to make it.
The current design doesn't allow changing the search parameters or list of mailboxes, otherwise it breaks more or less badly. I guess I could add code to check if the dovecot-virtual file's mtime has changed and if so make it do a full resync. This anyway means that there's no way to support wildcard mailbox names (e.g. "all mailboxes"). But does anyone really want that (yet)? It'll anyway be faster/easier to implement once mailbox list indexes are implemented.
Changing mailbox list is now detected and handled, as well as UIDVALIDITY changing in mailboxes. Mailbox list wildcards wouldn't be all that difficult to implement anymore if someone wants them, but until then I don't think I'll bother.
Changing search parameters still isn't detected though. Maybe it could store a MD5 sum of the search parameters in the header and if it changes rebuild the entire mailbox.
I'll still have to add a new X-MAILBOX search parameter which can be used to test what the backend mailbox name is. This will be especially useful with INTHREAD extension. I guess it wouldn't hurt to have FETCH X-MAILBOX if someone wants it.
Oh, almost forgot about this one.
- INTHREAD extension isn't started yet, but I'll start it soon. Hopefully won't be too tricky to get it working with virtual mailboxes and CONTEXT=SEARCH..
This one is the last major unimplemented v1.2 feature. After that I'll start finishing, optimizing and stabilizing the features for a v1.2 release (as well as start v2.0/replication coding). I'm hoping for v1.2.0 release by the end of this summer.