On Mo, 2011-09-12 at 17:13 +0800, Oon-Ee Ng wrote:
Hi all, the only results I can find from searching the error were
way
back in 2009 (and the OP did not follow up in any case) and some
Ubuntu forums thing. I'm assuming the error is because some contact in
my google contacts is messed up (I'm syncing through everdroid), any
way for me to find out which one?
$ syncevolution --sync refresh-from-server everdroid
[INFO] calendar: inactive
[INFO] todo: starting first time sync from server
[INFO] addressbook: starting first time sync from server
[INFO] memo: starting first time sync from server
Local data changes to be applied remotely during synchronization:
*** memo ***
no changes
*** todo ***
no changes
[ERROR] addressbook: contact entry without REV:
http://www.google.com/m8/feeds/contacts/ngoonee%40gmail.com/full/2fbd43f9...
This is the Evolution Google contacts backend, right?
Sorry, an Evolution contact backend must support REV to be used in
combination with SyncEvolution.
To synchronize with Google contacts, there are different options:
1. SyncML - working in 1.1: fairly limited because Google exposes
very little data, for example no BDAY; unlimited number of phone
numbers should work
2. ActiveSync - should be working with the latest source (only
Exchange 2010 tested, though): BDAY working, but addresses and
phone numbers limited by what the ActiveSync supports (see my
"ActiveSync contact support" email)
3. Google Data API via EDS: not working because of missing REV
support in EDS backend, could be a conceptual problem
4. Google Data API via SyncEvolution backend: no code written, just
an idea
I think that option 4 has the biggest potential. It gives SyncEvolution
raw access to Google's data, with no intermediate conversion or APIs in
the way. It's also most work to get there. If anyone wants to have a go
at it, then I'd be happy to help. Heck, I'd like to do it myself if I
had the time.
--
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.