wasm-demo/demo/ermis-f/imap-protocol/cur/1600095105.22743.mbox:2,S

40 lines
1.9 KiB
Plaintext

MBOX-Line: From brong at fastmail.fm Wed Mar 28 00:48:48 2012
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun 8 12:34:48 2018
Subject: [Imap-protocol] using a global CONDSTORE mod-sequence for
HIGHESTMODSEQ
In-Reply-To: <DCC0D549-0C19-4D6A-9038-729DC3A551A8@iki.fi>
References: <CABHfyPTqCCkhERdbrZbix8zyqc=OjHPPCtcb0NeA4LdDhrnCww@mail.gmail.com>
<20897.1332887190.012640@puncture>
<DCC0D549-0C19-4D6A-9038-729DC3A551A8@iki.fi>
Message-ID: <20120328074848.GA2878@launde.brong.net>
On Wed, Mar 28, 2012 at 01:42:23AM +0300, Timo Sirainen wrote:
> On 28.3.2012, at 1.26, Dave Cridland wrote:
> > It'll work, it just might be less efficient.
> >
> > But if the client is using QRESYNC, it'll be no different at all, I suspect.
>
> Well, some QRESYNC capable clients might think that they're being smart and syncing only mailboxes that have changed, but in this server all of the mailboxes have changed, so the client might SELECT all of them.. Then again I don't know if any clients are really doing (or planning to do) that.
>
> Would work better if you kept a per-mailbox HIGHESTMODSEQ even if they point to one shared modseq counter.
That's what we're doing in conversations-enabled Cyrus at FastMail. I
haven't yet pushed it to master for 2.5, but it's probably what we'll do.
One counter across the entire user, but then keeping the actual HIGHESTMODSEQ
per folder.
The more interesting bits are how to handle shared mailboxes in this case.
I suspect every one will be its own "modseqroot", rather than the shared
root per user.
The good thing about the global counter is that we have a special call to
read just that, and if it hasn't changed then we know ALL folders are
unchanged. We also keep a global UIDVALIDITY counter per user, and any
rename, create or delete increments that counter, so we can just use the
single counter to know if a new LIST needs to be sent.
Bron.