49 lines
3.3 KiB
Plaintext
49 lines
3.3 KiB
Plaintext
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>" :)
|
|
|
|
|