On Sun, 2011-12-04 at 10:04 -0700, Sankar P wrote: > My memory is very rusty and I have not seen Evolution sources in more > than 3 years now. However, we had a similar situation when we working > on a GroupWise backend and we used a trick to get the number of > messages in a folder on startup of Evolution (or when the user > explicitly presses the getmail button) and try to compare the mail > counts between summary and server and update if they differ (and > obviously, after fetching new items in this delta) > > I am not sure if Exchange server has such a count API. If so, it can > be used without breaking the summary code much. We do something similar to that for IMAP — using the counts as a sanity check and falling back to the old-style non-QRESYNC method of refetching the flags for *every* message in the folder. I don't believe we have fallback like that for EWS and ActiveSync. Those didn't have sane delta-based operation 'tacked on' to an old protocol which we can fall back to; they were designed to be delta-based from the *start*, and the client is expected *not* to get itself out of sync. Even if we could detect a problem in ActiveSync, we'd basically have to refetch the entire folder to recover — and that would mean that message IDs all change, so our cache has to be entirely blown away. I *think* we could keep the cache in EWS and just refetch the message details, but I still don't like it — it would be a horrid workaround for a bug, if we ever have to use it. When the server responds, it tells us "here are a bunch of changes, and your new 'bookmark' for the folder state is XXX". We should remember that, atomically. If we crash, our cache on restart should reflect either the state *before* the response, or the state *after* it. Never something in between. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature