Re: [Evolution-hackers] RFClue: Atomic folder updates

[Milan Crha <mcrha redhat com>]

On Tue, 2011-12-06 at 00:09 +0000, 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 the changes we were originally given in the
> XXX->YYY delta have now been *reverted* (like a message being marked
> read and then unread, or created and then deleted).

	Hi,
thanks for the explanation, it makes sense and I didn't think of it this
way before.

> If Evolution's cache storage can't give us that atomicity, then we
> should be able to fake it. I suspect the best answer is to write the
> server's response to disk before processing it. On startup, we can check
> if any such changes are outstanding and need to be "replayed".
> 
> We'll *still* be replaying "changes since XXX" to a folder state which
> doesn't actually match XXX, but at least it'll be the *same* set of
> changes. That actually makes it OK.

That's basically what I tried to express with my a),b),c),d), only in a
level of CamelFolderSummary, without any extra files being involved.

> > Nonetheless, there are people whom are willing to connect to their
> > exchange account from multiple machines. Did you try whether this sync
> > can work in such environment, please?
> 
> Yes, I've been using EWS from both my laptop and my desktop for much of
> the last year (until I switched focus to ActiveSync; now I run only on
> one since I got a new laptop and haven't yet configured EWS on it).

I agree, after your above explanation. There should not be a problem to
use more clients if it works as you described.
	Thanks and bye,
	Milan