MBOX-Line: From tss at iki.fi  Tue Mar 27 15:42:23 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] using a global CONDSTORE mod-sequence for
	HIGHESTMODSEQ
In-Reply-To: <20897.1332887190.012640@puncture>
References: <CABHfyPTqCCkhERdbrZbix8zyqc=OjHPPCtcb0NeA4LdDhrnCww@mail.gmail.com>
	<20897.1332887190.012640@puncture>
Message-ID: <DCC0D549-0C19-4D6A-9038-729DC3A551A8@iki.fi>

On 28.3.2012, at 1.26, Dave Cridland wrote:

> On Tue Mar 27 22:49:55 2012, John Galton wrote:
>> The RFC states that the mod-sequence represents the highest modification to
>> a given mailbox.  If a mailstore only stored a global (account-wide, across
>> all mailboxes) mod-sequence, could one simply return the current value of
>> such a global mod-sequence when the HIGHESTMODSEQ is called for
>> (SELECT/EXAMINE/STATUS)?
>> Obviously using this value would trigger the client to followup with a
>> request to find out what has changed since it last sync'd, even if nothing
>> has changed.  Should a client be expected to behave reasonably if it's
>> FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest
>> mod-sequence was less than the advertised HIGHESTMODSEQ or worse, there
>> were no results at all when some were expected?
> 
> 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.


