MBOX-Line: From tss at iki.fi  Tue Nov 27 02:38:30 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] Re: Suspend/Restore feature proposal
In-Reply-To: <1354010952.13681.140661158661065.2086C60B@webmail.messagingengine.com>
References: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
	<CABa8R6tHP2My0k2LqT1RzHoLQZA+X_jwUMU0cydm2sAwo8f4Fg@mail.gmail.com>
	<20121116143137.Horde.7Kb3aEW5DhM6CnuA2hAx4Q8@bigworm.curecanti.org>
	<e122fa25-9110-4b36-855d-0e7e273c5805@flaska.net>
	<20121121155417.Horde.ZeW7JqTPNxTAI-hTtrAT-Q9@bigworm.curecanti.org>
	<CABa8R6sJfnA=HYk-fmFfpXki91cne_LeqFyuhDebMGeDdsdj7g@mail.gmail.com>
	<20121121183606.Horde.8DDdRoJ261AbQsAiMPfS4w1@bigworm.curecanti.org>
	<CABa8R6u62m0SkAoLa+K8MgQn8CXKxtv5Hnnt6O1muTZQnFqqoA@mail.gmail.com>
	<20121126152005.Horde.UGsoLB91esWQF9_aGi6UYQ1@bigworm.curecanti.org>
	<CABa8R6tGF8Uj-MEec6vdHrhkYefhiU0QLGtVXafDwOXb3vnFmQ@mail.gmail.com>
	<20121126155721.Horde.a3j2EWFDFOo-xkaflrURBQ2@bigworm.curecanti.org>
	<CABa8R6tOshnrGPGCdb0QToAx8xjWVWY+RBu0Uw8cZ2NH3=TvZw@mail.gmail.com>
	<1354010952.13681.140661158661065.2086C60B@webmail.messagingengine.com>
Message-ID: <CD24D84B-783A-4E32-9C9B-9C8D262EC5C1@iki.fi>

On 27.11.2012, at 12.09, Bron Gondwana wrote:

> I like QRESYNC a lot more now that I've implemented the Cyrus 2.4+ replication
> protocol on top of it.  It basically uses the same logic, but with full
> information required to replicate the exact mailbox state at the far end.  It
> means fast and cheap resync.

Dovecot is using the same underlying qresync features as well, although not qresync itself.

> I'm really tempted to try to write it up as a more general protocol for
> synchronising IMAP message stores from any vendor.  There's some capabilities
> you need which can't be expressed over regular IMAP - for example appending
> with a specific new UID rather than the next available.

I think that's the only one that is pretty much required, for both APPEND and COPY. Although exposing this to regular users could become troublesome. I know Dovecot doesn't handle it very nicely when you run out of UIDs. (I used to try to handle it a long time ago by giving new UIDs to messages, but I haven't tested it for ages now. And that wouldn't really work with the newer mailbox formats. So I guess simply failing to add any new messages until mailbox is deleted would work too. But then I'd need to support deleting INBOX..)

I'm also planning on adding support for syncing from regular IMAP server to Dovecot, mainly for migration purposes. It would still need to be at least partially two-way sync. I've been wondering if I should try to sync the UIDs on the IMAP server side as well. It could be done with enough COPY+EXPUNGE commands for a single message. :)

> I also wrote up a long thing to the Cyrus mailing list many years ago about
> "UID Promotion" - basically if the two ends had ever had different messages
> with the same UID, you need to give new UIDs to BOTH messages which are
> higher than any ever seen by any client - generating an EXPUNGE and two
> APPEND events at each end - to come entirely back into sync.

I implemented this with "COPY <old uid> <new uid>" + "EXPUNGE <old uid>". Much simpler than my original plan to implement "CHANGEUID <old> <new>" :)


