I have been working on sync on and off for many years but I don't have any obvious solutions to propose. The array problem, in particular, is essentially the issue that made me eventually give up on OpenSync (along with the fact that everyone had drifted away from it). Particularly when you consider that some devices will systematically appear to have changed the array on every sync due to their own limitations (number of entries supported, limited type information retained, etc).
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 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. In the short term, the most critical thing is to allow the user to see what is happening, and to fix it if necessary. 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. 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) 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. Sorry this doesn't help with your specific questions! Graham _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
