Hello Frederik, beware, potential Genesis incompatibility in SyncEvolution 1.0... keep reading.
On Thu, 2010-01-14 at 20:31 +0000, Bommaraju, Rajyalakshmi wrote: > May be consider changing "Synchronization Completed Successfully" to > "Sync session completed successfully" to indicate that we are talking > about session not the content. To me, a session which does not synchronize all content wasn't successful. > And if we know for sure that the local changes have problems, return > error codes so that, "Synchronization partially successful" then users > will look at the rejected items and deal with the problematic items. This is what I have implemented. In contrast to what I said earlier, I didn't update libsynthesis to provide more detailed statistics. It would be possible for local errors, but for remote errors it looked a bit more difficult to attribute the error to an add/update/delete. In addition, when I tested it, I found that a source error on the SyncML server for one item showed up as a failed overall sync anyway. So what I have done instead is to correctly display the information that we get from the engine. The "rejected/total" ratio is gone (because we don't have the "rejected" part) and a "ERR" column was added. I struggled a bit to make it more obvious that a failed "add" will contribute to both the "ADD" column and the "ERR" column, but haven't found a good solution. Furthermore, once the ERR is non-zero for a source which otherwise is okay, a 22001 "partial failure" status will be recorded. Here's what this looks like in the command line output: +---------------|-----------------------|-----------------------|-CON-+ | | LOCAL | REMOTE | FLI | | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | addressbook | 32 | 0 | 32 | 2 | 0 | 0 | 0 | 0 | 0 | | refresh-from-server, 0 KB sent by client, 33 KB received | | item(s) in database backup: 32 before sync, 30 after it | | some changes could not be transferred (local, status 22001) | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | calendar | 13 | 0 | 13 | 0 | 0 | 0 | 0 | 0 | 0 | | refresh-from-server, 0 KB sent by client, 7 KB received | | item(s) in database backup: 13 before sync, 13 after it | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | start Fri Jan 15 15:54:18 2010, duration 0:09min | | some changes could not be transferred (local, status 22001) | +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ This is a change in the output of the command line tool, so Genesis might have to be updated - or rewritten to use the D-Bus API ;-} -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
