[prev in list] [next in list] [prev in thread] [next in thread] 

List:       c-client
Subject:    Re: caching and mailbox synchronisation with c-client
From:       Mark Crispin <MRC () CAC ! Washington ! EDU>
Date:       2005-04-14 19:19:15
Message-ID: Pine.WNT.4.63.0504141205250.1964 () Shimo-Tomobiki ! panda ! com
[Download RAW message or body]

As a first order approximation:

You should have on record the UIDVALIDITY of the mailbox, highest assigned 
UID in the mailbox ever seen by the client, and UIDs of all messages.  If 
the IMAP server reports a different UIDVALIDITY then what you have, dump 
your entire cache; it has been invalidated so you have to reload 
everything.

Otherwise, if the UIDVALIDITY is the same, then identify new messages by 
doing "tag UID FETCH <n+1>:* FAST" (instead of "FAST", you may want "ALL" 
or "FULL" or whatever else you would like to know about new messages at 
synchronization time).  For <n+1>, substitute the highest assigned UID 
plus 1.

For example, if the highest assigned UID is 4392, then do something like:
 	tag UID FETCH 4393:* FULL
and load your cache with the returned data.

If you only get back one message, then that message is the 
highest-numbered UID message in the mailbox (not necessarily the highest 
UID ever assigned, since subsequent messages could have been deleted and 
expunged).

Next, compare the number of messages you have cached with the number of 
messages reported by EXISTS in the response to SELECT.  If this is 
different, the EXISTS value is probably smaller than what you have, 
meaning that many messages had been deleted and expunged (if EXISTS is 
larger, then you have a bug in your application since you failed to cache 
some old message).

An easy way to determine what messages were deleted is to fetch the UID 
map of the old messages with "tag UID FETCH 1:<n> UID" (where <n> is the 
highest assigned UID as above).  A slightly less chatty way to do this is 
"tag UID SEARCH UID 1:<n> ALL".  The UIDs that aren't returned are the 
ones that you need to remove from your cache.

This is a pretty simpleminded mechanism.  It's possible to do a lot 
better, particularly by observing that sequence numbers have no holes and 
that UIDs are strictly ascending; these are very useful properties.  But 
"learn to walk before you run" is a good point here; start with something 
simple like this, and then try to make it fancier.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
[prev in list] [next in list] [prev in thread] [next in thread]