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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers