On Fri, 2016-11-18 at 14:08 +0000, Graham Cobb wrote: > On 18/11/16 13:03, Patrick Ohly wrote: > > With multi-way you mean a sync topology that has cycles? Yes, that's > > indeed not possible with SyncEvolution. I also don't see a way to do it > > as long as one is stuck with existing data formats. > > Actually, I meant even without cycles. It seems to me from my own > experiments that it is impossible (in the real world) to keep N > 2 > devices in sync just using pairwise syncs (assuming changes on any > device, but disallowing conflicting changes). The main problem is > different sets of supported attributes. > > That was the problem OpenSync tried to solve (with its centralised > database and lists of supported attributes) but SyncEvolution ignores (a > very reasonable but large simplification).
SyncEvolution can be used in such a mode - one just needs a central hub which supports the full semantic and attributes of everything that one wants to sync, and the description of what each peer supports has to be accurate. Unfortunately, in practice both conditions aren't completely met. SyncEvolution has to be the SyncML server, too, which it is, under the hood, when using SyncEvolution with ActiveSync or CalDAV/CardDAV. As soon as one allows to let a remote SyncML server do conflict handling, one is pretty much at the mercy of that server. > I have tried to simulate this by using a files backend as a common point > to synchronise everything with, but I still see a lot of spurious > changes and corruptions being propagated around. The file backend is a bit limited in that it does not fully support iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't know about relationships between items sharing the same UID. I'm not sure anymore what the implication was in practice - might only be relevant when dealing with peers which themselves do not support the semantic. > That means that, for the time being, I am forced to treat Outlook as my > master and only do one-way syncs from there to my other devices. I suspect the reason for the spurious changes was more related to poor conversion between Outlook data formats and the master storage. As soon as a peer is expected to store data correctly and then doesn't, that undesired modification may get propagated back. That happens also in 1:1 syncs and is unrelated to multi-way syncing. -- 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 SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution