On 18/11/16 15:06, Patrick Ohly wrote:
SyncEvolution can be used in such a mode - one just needs a central
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
I don't think either condition is anywhere near being met.
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 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!).
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
If I remember correctly, this restriction is an issue for recurrence
exception handling. But I haven't looked into it recently.
I suspect the reason for the spurious changes was more related to
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.
There is certainly a serious issue with Outlook as some of the object
semantics are just different from the implied semantics in the vformats
and cannot be reliably converted.
But I also see problems with Owncloud & KDE. It particularly affects
non-standard attributes, which keep coming and going and never stabilise
even when no changes are happening on any device.
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.
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.
Maybe when I retire I will have time to do more work on this.