MBOX-Line: From brong at fastmail.fm  Wed Mar 21 06:01:39 2012
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] CONDSTORE mod-sequence values
In-Reply-To: <4F69AABD.4070206@gulbrandsen.priv.no>
References: <CABHfyPSq=7hOtH94aet6T=osoXmfVP94iAq6iCCYH3N+MvGmFw@mail.gmail.com>
	<1370186682.140190.1332276137465.JavaMail.root@zimbra.com>
	<CABHfyPRH8_FGaDhx6s5rnhk6B=bcuqeoWTm00=6aktBVA-3t5A@mail.gmail.com>
	<4F69AABD.4070206@gulbrandsen.priv.no>
Message-ID: <1332334899.13815.140661052117053.5297D8C5@webmail.messagingengine.com>



On Wed, Mar 21, 2012, at 11:17 AM, Arnt Gulbrandsen wrote:
> As long as no client ever gets to see MODSEQ 1000 for two different
> states (such as another client's half-completed command and the same
> command fully completed), everything is fine.

That's certainly how I see it.  In the extreme, you could even lazily
allocate MODSEQ only when a client requests the information (including,
obviously, a MODSEQ enabled client doing a change and expecting a new
HIGHESTMODSEQ in the response)

But any non-MODSEQ based access to the store could not bump it at all,
so long as the next time a MODSEQ enabled client connected, the MODSEQ
got allocated to all changed things since then.

At least, I can't see how any client could know the difference, or be
right in caring.  The only points in time it can know about are right
now, and last time it did a read and got a MODSEQ out of it.  Ordering
of the MODSEQs within that are unimportant (to this particular client)

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm


