[SyncEvolution] Sync with SailFish OS via Bluetooth

[Patrick Ohly]

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.