MBOX-Line: From brong at fastmail.fm  Fri Dec 28 14:17:38 2012
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Missing UIDNEXT during mailbox synchronization
In-Reply-To: <1356732787.18647.140661171122177.5EB821AB@webmail.messagingengine.com>
References: <db123879-1082-4911-b7ce-3a861d62217a@flaska.net>
	<20121228112725.Horde.cM7EjLQoqQDix9dQMs5KcA1@bigworm.curecanti.org>
	<1356723190.15576.140661171078629.69B791C0@webmail.messagingengine.com>
	<20121228130129.Horde.VTgbGtjlIvg0wUwlkp5dDg6@bigworm.curecanti.org>
	<1356732787.18647.140661171122177.5EB821AB@webmail.messagingengine.com>
Message-ID: <1356733058.19335.140661171123477.7DDFF57D@webmail.messagingengine.com>

On Fri, Dec 28, 2012, at 11:13 PM, Bron Gondwana wrote:
> On Fri, Dec 28, 2012, at 09:01 PM, Michael M Slusarz wrote:
> > Quoting Bron Gondwana <brong@fastmail.fm>:
> > >> For cache purposes, you can workaround a missing UIDNEXT response by
> > >> doing a 'UID FETCH * (UID)' in the mailbox.
> > >
> > > Ouch.
> > 
> > I assume this means this is a slow operation server-side (at least in  
> > Cyrus).  I personally don't care since it is a viable way of working  
> > around a possible RFC violation.  Performance isn't an issue here.
> 
> No, actually - it should be pretty quick.  I don't think it even needs to
> do a search of the address space, it should just read the last item if
> * matches uid_last.  Otherwise it will do a binary search of the index
> map.
> 
> But of course Cyrus always returns UIDNEXT anyway.
> 
> > > The more interesting question is: what do you need to know it for anyway?
> > 
> > To determine if the mailbox has changed to prevent an issuance of an  
> > unneeded FETCH/SORT command.  Flag changes are irrelevant (if  
> > CONDSTORE isn't available), since clients can be designed to not care  
> > about these changes
> 
> Fair enough I guess, if you really don't need the data from those intermediate
> records.  Otherwise you may as well just do fetch $olduid+1:* (stuff you need),
> which will be the same number of round trips as your solution in the trivial
> case, and one fewer in the case where there is new data to know.
> 
> Let's play make believe for a second with Cyrus though:
> 
> . select inbox
> * 2 EXISTS
> * 2 RECENT
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Ok
> * OK [UNSEEN 1] Ok
> * OK [UIDVALIDITY 1356732706] Ok
> * OK [UIDNEXT 3] Ok
> * OK [HIGHESTMODSEQ 5] Ok
> * OK [URLMECH INTERNAL] Ok
> * OK [ANNOTATIONS 65536] Ok
> . OK [READ-WRITE] Completed
> . fetch 1:* (uid)     
> * 1 FETCH (UID 1)
> * 2 FETCH (UID 2)
> . OK Completed (0.000 sec)
> . fetch * (uid)
> * 2 FETCH (UID 2)
> . OK Completed (0.000 sec 

Sorry - cat on keyboard failure.

)
. store 2 +flags \Deleted
* 2 FETCH (FLAGS (\Recent \Deleted))
. OK Completed
. expunge
* 2 EXPUNGE
. OK [HIGHESTMODSEQ 7] Completed
. fetch * (uid)
* 1 FETCH (UID 1)
. OK Completed (0.000 sec)

That definitely doesn't work!

. uid fetch * (uid)
. OK Completed (0.000 sec)

And that contains nothing.  You can't know from that if stuff got added and
expunged since your last request though.

Consider:

UIDs 1 3 4 5 7 
EXISTS 5
UIDNEXT 10

APPEND 11 12
EXPUNGE 4 12

UIDs 1 3 5 7 11
EXISTS 5
UIDNEXT 13

Your query couldn't tell the difference between state A and state B.

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm


