[SyncEvolution] Sync with SailFish OS via Bluetooth

[Patrick Ohly]

On Fri, 2016-11-18 at 16:35 +0000, Graham Cobb wrote:
> On 18/11/16 15:06, Patrick Ohly wrote:
> > 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.
> 
> I don't think either condition is anywhere near being met.

Darn, there goes my self-delusion.

> What backend would you suggest can be used which "supports the full
> semantic and attributes of everything that one wants to sync"? I am not
> aware of one, but I have only tried a few.

The EDS backend has full iCalendar 2.0 support and fairly complete vCard
3.0. In both cases, additional properties can be (okay, could be) stored
as extensions. However, Evolution itself does not know about custom
SyncEvolution-specific extensions (should they get added), so while in
theory it should leave them alone, in practice that's not guaranteed.

The same is true for CalDAV and CardDAV servers: extensions are supposed
to be stored and preserved, but not everyone follows that.

> The second condition is the most serious.  In my experience of my many
> devices over the years, the question of support is the hardest.  The
> combinations of design limitations, bugs and strange interactions
> (attribute X can't be set if attribute Y is set) is really hard to
> define.  Even in the case where I knew the code intimately (the GPE
> implementation for Maemo) the description language could not express the
> restrictions I knew about (let alone the unknown bugs!).

True. The profiles in SyncEvolution try to take care of different
representations, but there are always differences that are going to be
problematic.

> > That happens also in 1:1 syncs and is unrelated to multi-way syncing.
> 
> In my experience it is a much smaller problem in 1:1 cases: typically
> things are either supported or not and the worst I see is that syncs may
> keep trying to set data which is being ignored -- but no database
> changes actually occur on either side if nothing has changed. In the
> multi-way case, that turns into the data changing with attributes
> toggling on and off or changing values as syncs with different devices
> occur, even when no data has actually changed. I haven't looked into it
> for some time but I seem to remember that it is partly due to the syncs
> not being part of a single sync but appearing to be subsequent events,
> making changes that then have to be propagated to other devices.

Hmm, when items don't change, no changes should be applied and syncing
repeatedly should be stable.

> I am not blaming SyncEvolution -- I am just not convinced that multi-way
> sync can ever be replaced by a series of two-way syncs.

That's something that would be worthwhile investigating in depth. Until
then we have to agree to disagree ;-}

-- 
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.