Re: [Imap-protocol] Missing UIDNEXT during mailbox synchronization

Bron Gondwana <[email protected]>
Newsgroups gmane.mail.imap.general
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 <[email protected]>:
> > >> 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
  [email protected]

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.