Re: [Imap-protocol] Re: Suspend/Restore feature proposal

On Tue, Nov 27, 2012, at 12:30 AM, Brandon Long wrote:
> On Mon, Nov 26, 2012 at 2:57 PM, Michael M Slusarz <[email protected]>wrote:
> > What I get out of this is that you think QRESYNC was the result of an
> > incorrect design decision and, instead,  the proposal you previously linked
> > to in this thread should have won out.
> 
> I wasn't on the list at that time, so I have no idea what the debate looked
> like.  I view them as different, however.  QRESYNC requires little extra
> storage and can be persisted for any length of time.  I find it odd that it
> mentions "mobile, frequently disconnected" as its still a fairly extensive
> negotiation between client and server.  Its certainly a win for any client
> when re-connecting, regardless of how long ago that was, and fills a hole
> in the CONDSTORE case.  So no, I don't think QRESYNC is an incorrect design
> decision.  Its possible a "not imap" protocol could conceive of a better
> way, in syntax or otherwise, of passing the needed information to re-sync
> the client and server, but QRESYNC has to fit the task given it.

The interesting part for QRESYNC is remembering "tombstones" for EXPUNGED
messages for a while to keep it cheap.

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.

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 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.

If anyone else is interested, I can write up something about how Cyrus
implements QRESYNC now, such that it can clean up old records, yet still
be efficient for clients most of the time.

Bron.

-- 
  Bron Gondwana
  [email protected]

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol