On Mon, 2014-04-14 at 13:14 +0100, Graham Cobb wrote: > Thank you for your contribution, Ove. Interestingly, I actually find > this way of thinking about local sync (that it is a hack to sort of > extend SyncML to other protocols) unhelpful. As both you and Patrick > have mentioned that, I realise that this is how it came about, but I > tend to think it causes additional confusion as it makes non-SyncML > protocol access look like more of a special case (with its own rules to > be learnt) than is really the case with the (brilliant) way Patrick has > implemented it. Of course, I may be unique in this and others may find > it very helpful -- just a data point. > > I prefer to think of local sync as purely an optimisation on a sync > which happens between SyncML entities which happen to be on the same > system (and which can be completely replaced with a normal SyncML sync > if they are on different systems).
Is there really a fundamental difference between your view and Ove's? You both view it as a SyncML client<->server sync. The difference is that Ove leans more towards considering that a hackish implementation detail, whereas you see it as a first-class concept that users need to know and understand. > In the context of SyncEvolution I think of WebDAV and ActiveSync not as > sync protocols but primarily as database access protocols, and all the > database backends in SyncEvolution as being equal. That's correct. WebDAV really isn't a sync protocol, it just has some support for concurrent access to item collections without offering any means for resolving conflicts. ActiveSync could be used as a sync protocol (by relinquishing control over the local copy of the data to the server); SyncEvolution doesn't use it like that and instead just uses it to get changes and reading/writing items. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
