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