[SyncEvolution] Google Contacts vCard Incompatibility (cardDAV)

Sunny Sigara sunnysigara at gmail.com
Tue Feb 18 23:28:04 UTC 2014


On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly <patrick.ohly at intel.com> 
wrote:
> It's unrelated to your problem, I'm just curious: did you use GNOME
> Online Accounts or did you compile from source for Ubuntu Online
> Accounts?
> 

Its GOA. 

But one thing I like to mention here is that: v1 api endpoints are 
still working for calDAV & cardDAV 
with basic http authentication (only for whitelisted applications, I 
suppose). For example,

"syncevolution --print-databases \ 
	backend=carddav \ 
	username=username at gmail.com password=****** \	
	syncURL=https://www.googleapis.com:443/ "

gives same default database as this:

"syncevolution --print-databases \ 
	backend=carddav \
	username=goa:username at gmail.com \
	syncURL=https://www.googleapis.com/.well-known/carddav ".

Here is the test setup for both (caldav): 
http://paste.ubuntu.com/6957096/



> With "it" you mean the Google web interface, right?
> 

Yes. Its Google Web interface.


>  Instant messaging
> fields do get synchronized to the server and come back, but the server
> probably doesn't understand the properties used by Evolution (X-AIM,
> etc.) and SyncEvolution does not yet translate between Evolution and
> Google.
> 
> My summary of the current status from the initial release still 
> applies
> because I haven't had the time to improve the data mapping:
> 
>         Support for Google CardDAV is new. Like Evolution, 
> SyncEvolution does
>         not yet support some of the advanced features of the server, 
> in
>         particular custom labels for phone numbers, emails and
>         addresses. Likewise, some client properties are not supported 
> by the
>         server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not 
> supported. Of
>         ORG, only the first two components are supported.  Currently,
>         properties not supported by one side get lost in a full 
> roundtrip
>         sync.
> 
> Although not mentioned, instant messaging fields fall into the same
> problem space.
> 

That explains everything. Also also from 1.4 release notes, its crystal 
clear:

"Instant Messaging information is supported by both sides with
different vCard extensions; the server stores these extensions without
showing the information, while SyncEvolution drops the data sent by
the server."


> The duplication shouldn't happen. I'll test that tomorrow, and/or you
> can send me the syncevolution-log.html files (sync config and target
> config) from such a sync. Best run the sync with loglevel=4.
> 

I think, I spoke too soon here. After reformatting local & remote 
databases I
couldn't able to reproduce the problem.



>>  4) If I change anything on "Bruce Banner" locally, log says changes
>>  added but doesn't appear in Google(?).
>> 
> Again, logs with loglevel 4 would be more useful than the sync ouput 
> in
> the shell window.
> 

I attached the log. But I don't think further investigation on this is 
necessary,
as you explained, how some client properties ((CALURI, CATEGORIES, 
FBURL, GEO)
are not supported by the server (yet).

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/syncevolution/attachments/20140218/233d4eec/attachment.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/syncevolution/attachments/20140218/233d4eec/attachment.html>


More information about the SyncEvolution mailing list