[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