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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to