Hi Timo,
First of all, dovecot is great! :)
Question on CONDSTORE. I haven't re-read RFC to confirm, isn't
CONDSTORE operates under switch mode with command ENABLE? So that IMAP
client needs to request such capability. Maybe I mixed up with another
IMAP command.
Thanks
Joseph
Timo Sirainen wrote:
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:
http://hg.dovecot.org/dovecot-1.2/
Nightly snapshots are also from v1.2 code tree nowadays.
1. 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.
4. 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.
6. 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.
