Hello Timo,
Thank you very much for planning a redesign of the dsycn and for opening this discussion.
As I can see from the replies that came until now everybody misses the main point of IMAP: IMAP has been designed to work as a disconnected, high-latency data store.
To make this more clear: once and IMAP client finishes the synchronization with the server, both have client and server have a consistent state of the mailbox. After this both the "client" and the "server" act like master for their own local copy (on the "server" new emails get created etc, on the "client" existing emails get changed (flags) and moved, and new emails appear (sent items)).
So the protocol is designed, originally, to handle the master-master replication. And as this it make sense a deployment global-wide, where servers work independently and from time to time they "merge" the changes.
This being said and acknowledged here are my 2 cents:
I think that the current '1 brain / 2 workers' seems to be the correct model. The "the client" connects to the "server" and pushes the local changes and after retrieves the updated/new items from the "server". "The brain" considers first server as the "local storage" and the second server as "server storage".
For the split design, "come to the same conclusion of the state" is very race-condition prone.
As long as the algorithm is kept as you described it in the original document then the backups should really be incremental (because you only do the changes since last sync).
As the most changes are "metadata-only" the sync can be pretty fast by merging indexes.
Thank you, Andrei
In case anyone is interested in reading (and maybe helping!) with a dsync redesign that's intended to fix all of its current problems, here are some possibly incoherent ramblings about it:
http://dovecot.org/tmp/dsync-redesign.txt
and even if you don't understand that, here's another document disguising as an algorithm class problem :) If anyone has thoughts on how to solve it, would be great:
http://dovecot.org/tmp/dsync-redesign-problem.txt
It only deals with saving new messages, not expunges/flag changes/etc, but those should be much simpler.
!DSPAM:4f6cea4c260302917022693!