27 lines
1.8 KiB
Plaintext
27 lines
1.8 KiB
Plaintext
MBOX-Line: From tss at iki.fi Fri Jun 14 10:55:20 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Synchronizing multiple mailbox
|
|
In-Reply-To: <1371213398.8438.140661243890973.11ABE89B@webmail.messagingengine.com>
|
|
References: <CALog5aJ4rz8J7UxY3FPNoxVVHe1cMex3QR8PPvfB2_A9FVudJw@mail.gmail.com>
|
|
<1371204522.10116.140661243848077.263DB050@webmail.messagingengine.com>
|
|
<2C3638E0-49E6-4F8B-B998-7923F5FFEA8A@iki.fi>
|
|
<1371213398.8438.140661243890973.11ABE89B@webmail.messagingengine.com>
|
|
Message-ID: <6F96B898-B612-4272-B322-7A693E1CE35D@iki.fi>
|
|
|
|
On 14.6.2013, at 15.36, Bron Gondwana <brong@fastmail.fm> wrote:
|
|
|
|
> On Fri, Jun 14, 2013, at 10:22 PM, Timo Sirainen wrote:
|
|
>> On 14.6.2013, at 13.08, Bron Gondwana <brong@fastmail.fm> wrote:
|
|
>>
|
|
>>> We cheat at FastMail - we've got a patched Cyrus server which uses a single HIGHESTMODSEQ counter per user, as well as a single MAXUIDVALIDITY. Since we always bump the UIDVALIDITY of folders on rename, create or delete (keeping a tombstone record), we only need to keep track of two numbers - one for any changes to the folder listing, and a second for any changes to any mailbox. This allows us to optimise our web interface significantly (and provide the same advantages to any future clients that talk to our JSON API directly).
|
|
>>
|
|
>> Won't the UIDVALIDITY change on RENAME invalidate the local cache even for the client that issued the RENAME command?
|
|
>
|
|
> It has no guarantee anyway. You can't keep the UIDVALIDITY on rename if the destination name previously existed with that same UIDVALIDITY. Which means it either has to either trust that it's still the same folder after rename?
|
|
|
|
I'm increasing UIDVALIDITY every time a new mailbox is created, so no two mailboxes have the same. This avoids conflicts with RENAME.
|
|
|
|
|