On Tue, 2011-12-06 at 00:09 +, David Woodhouse wrote:
> In fact, even that would be OK if we got the *same* answer. All of the
> changes we get given in a single update are perfectly fine to apply
> twice. The real problem happens if the folder has changed again in the
> meantime, and some of t
On Mon, 2011-12-05 at 09:49 +0100, Milan Crha wrote:
> I'm not sure if it's understood from your description, but the
> SyncKey on the exchange server changes as soon as the Sync call is
> finished (the server returns the new key), and asking with the old key
> results in this "bug".
Not quite.
On Sat, 2011-12-03 at 00:05 +, David Woodhouse wrote:
> The problem is, we need to handle these updates *atomically*. If we
> store the new timestamp before the changed messages, and we crash in
> the
> middle of doing so, then we might miss out forever on the messages in
> question. We'd resta
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 E
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 getmai
We have at least three mail protocols now which are delta-based. That
is, you have a bookmark, 'sync key' or timestamp which represents what
the server *last* told you about a given folder. You say to the server
"what changed since XXX", and get back a list of added/removed/changed
messages along w
