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
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
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
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
> That happens also in 1:1 syncs and is unrelated to multi-way
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
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.