On 09/04/14 13:49, Patrick Ohly wrote:
On Wed, 2014-04-09 at 12:45 +0100, Graham Cobb wrote:
> Conflict resolution/merging is a very hard problem, with no perfect
> solutions. It is really a separate issue which could do with much more
> research and co-ordinated effort, as the heart of the sync problem. I
> wonder if this could be separated out into a self-contained module so
> that different implementations could be tried (or even supported -- see
> below).
I doubt that a separate module would work outside of one particular
engine. It would be way too tightly integrated into data handling and
sync APIs of the engine.
I wasn't actually thinking about different engines -- I was more
thinking of allowing the SE engine to use different implementations of
conflict resolution (such as the interactive and non-intractive
mechanisms discussed later).
I agree. But the problem with the "real solution" is that
you end up
spending a lot more work on a relatively small improvement. Just to make
up some numbers, let's say that syncing works as expected 95% of the
times. To make it 99%, one would have to rewrite the entire sync engine
and easily spend again as much time as has gone into SyncEvolution
already.
That's just not realistic.
Indeed. But I can dream that maybe some academic or commercial
institute might want to solve this problem properly, one day. Time for
another Philippe Kahn!
> In the short term, the most critical thing is to allow the user
to see
> what is happening, and to fix it if necessary.
That's what the automatic backup, restore and DB diff (--print-changes)
is for. But not all users can enable that for performance and/or storage
reasons, or they won't know what to do with it.
Performance and storage are important but I don't think they are what
limits this today. I think it is usability. Particularly in terms of
undoing individual changes (even of individual fields within a single
object).
I've been told that Akonadi has something like this, and that
usability
is pretty poor. It is a hard problem to make such a system
user-friendly.
The blackberry solution seemed to be pretty usable. I have only used it
once but my recollections were positive.
> In the immediate case, I would suggest allowing some sort of
dry-run
> capability (frankly I have always been surprised this doesn't seem to
> exist today)
It's hard to do with the existing Synthesis engine (it expects the data
stores to really apply changes) and protocols. SyncML has sync anchors
and could in theory repeat the last sync, but I suspect that many
implementations will not implement that correctly. libsynthesis does (as
far as I know), but SyncEvolution doesn't.
I agree that relying on anchors would not be good. But having a dry-run
capability would be really useful even if it only worked, for now, on
local syncs.
You could disable printChanges. Then if you want, run synccompare
manually on the data dumps. There's no SyncEvolution command line
support for that, though, other than listing session dirs.
Yes, but I was thinking of better ways to do the print-changes job, by
driving it from the conflict resolution engine itself.
Personally I dislike the synccompare approach -- I have seen it report
strange things (like reporting two halves of two different entries as a
changed entry, presumably because it is doing textual comparisons on a
single file containing all entries) and taking forever to run on large
databases.
Could the engine which is assessing changes just write the changes out
(with the A and B values and the resulting changed value)? And how
about putting them in a database so that the user can be given a
post-sync tool which allows them to easily navigate through the changes
and go into more detail on the ones they are worried about? And maybe
even fix them in the local source (for syncing next time).
Graham