On Mon, 2010-04-05 at 20:59 +0100, martin f krafft wrote:
I got Funambol working and synchronised the N900 with it, using
syncevolution. I then installed Evolution and used syncevolution to
synchronise it, and while it downloaded all my contacts, it seems
like a lot of detail was lost. For instance, some phone numbers
didn't show up in Evolution, and several contacts didn't have
addresses anymore. I think this may be due to the VCard feature of
specifying e.g. Home vs. Work addresses.
I would like to find out how to track down the problem, but first
I need to understand how this SyncML stuff works. It seems like the
protocol does not just negotiate data records, but that it actually
knows about contacts and the individual VCard fields.
And then there is Funambol, which stores individual data with a type
ID field that I don't know how to translate (yet).
So I am wondering how and why some of the details of the contacts
aren't properly synchronised. This means I need to understand
exactly how the parts fit and work together. Is there a kind soul
out there ready to explain this to me?
This mailing list is a good start.
What docs should I read?
How about this one here:
http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard
Or does someone know why some details are being lost during
synchronisation, or even better: how to work around that?
Contacts get converted to and from vCards, the format used between
SyncML client and server, a few times. To investigate where things go
wrong you need to study log files of sync sessions where data is
transmitted. Because you are using SyncEvolution on both clients, that
would be a good starting point: set loglevel=4 on both to get item data
logged, then copy a new problematic contact from N900 to Funambol to
Evolution. To find the logs, use "syncevolution --print-sessions" or
simply look into your "logdir" (typically $HOME/.cache/syncevolution).
Check whether any information got lost or translated somehow by the
server.
If it happens on the server, then the server log might be useful, but
further discussions on this should be done with Funambol.
--
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.