2:05 a.m.
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.