5:49 a.m.
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 do have a gut feel that the best solution, one day, will be to try
to
merge changes, not merge databases. For now that would mean calculating
differences, but in the future protocols might actually allow sending
transactions instead of databases. I suspect that is the only real
solution to the array problem. But that is obviously not a short-term
solution.
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.
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.
Ideally, that would involve a user interface that allowed the user
to
see the proposed changes and authorise them (accept all changes, make no
changes, select which side wins particular conflicts, leave some
conflicts unresolved with different data on the two sides for now, log
all changes so the user can retrieve data they lost by mistake). This
is how my wife's blackberry<->Outlook sync seems to work.
If conflict resolution was a plugin, I could imagine one implementation
that had an interactive GUI to do all of the above, and another that was
designed for non-interactive operation. The latter would support a
"--dry-run" option that allowed the user to find out what changes would
be made, as well as output/logging which showed what conflicts occurred
and how they were resolved and which kept records of all data deleted in
case the user needed to re-enter it later.
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.
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.
and some improved output/logging to let people know what is
happening with conflicts: I find SE seems to output either far too much
info or far too little -- for example, enabling print-changes causes all
the useful info about the sync itself to scroll off the screen (even
with quite large xterm/screen scrollback buffers), but without
print-changes there is no way to find out what has changed. Having to
redirect output and then go through it carefully later in emacs is not
the solution. Defaulting to limited output explaining what is going on,
with options to retrieve more details later (from log files or from the
databases themselves) would help a lot.
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.
--
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.