On 16.4.2013, at 17.35, Thomas Hummel hummel@pasteur.fr wrote:
Besides, how about client side indexing while in this incoherent, not yet fully sync'ed state ? Wouldn't there be corruption risk ?
The worst that can happen is:
- Client sees new mail 123 in old server
- Client sees only mails up to 122 in the new server
- Client again will see mail 123 after a while
I'm actually not sure how clients will handle that. It is an IMAP protocol violation. It would be possible to add a new flag to dsync where it would treat all new emails as conflicts and give them new UIDs, so in the above case it wouldn't save a mail 123 but 124.
I see. But there are other cases :
for instance, the user deletes a mail foobar in the new server because he reconnects after the kick. I guess dsync would merge the change and would not sync the foobar message from the old server in the final step. But what if another , new, mail foobaz is delivered : would'it get the nextuid which was the uid of the deleted foobar mail, thus confusing the client local indexes ?
dsync in general resolves UID conflicts. If there's any chance that an IMAP client could have seen two different messages with the same UID, both of the messages get assigned new UIDs. That's why I was wondering only about the case that I mentioned. There the client couldn't have seen two different messages, but it's possible that some client could hide the mail 123 because it thought it got lost.