MBOX-Line: From brong at fastmail.fm  Wed Mar 21 15:06:49 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: <4F69E907.3000700@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>
	<1332334899.13815.140661052117053.5297D8C5@webmail.messagingengine.com>
	<4F69E907.3000700@gulbrandsen.priv.no>
Message-ID: <1332367609.5117.140661052351057.697AF222@webmail.messagingengine.com>



On Wed, Mar 21, 2012, at 03:43 PM, Arnt Gulbrandsen wrote:
> On 03/21/2012 02:01 PM, Bron Gondwana wrote:
> > 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.
> 
> Now you have a 64-bit number which changes seldom and a single-bit
> variable per message which goes to one for any change and to zero for
> any modseq allocation. That does not make much sense to me.

No - it's pretty silly for sure.  But if you're writing a server which
serves a Maildir which may also be updated by local clients which are
totally IMAP unaware, you're basically restricted to noticing that
"the following things changed".

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm


