[SyncEvolution] Google Contacts vCard Incompatibility (cardDAV)

[Patrick Ohly]

On Tue, 2014-02-18 at 23:33 +0005, Sunny Sigara wrote:
> 
> 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 ".

The syncURL is effectively the same, because
https://www.googleapis.com:443/ will cause .well-known/carddav to be
checked. But it is interesting that plain authentication still works. I
stopped testing that because it was meant to be disabled.



> > 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."

I added that in response to your report. Thanks for pointing it out, I
hadn't thought about all user-visible consequences before.

BTW, the "properties not supported by one side" only applies to the
standard vCard properties. As seen with X-AIM, extensions are preserved
by both Google. SyncEvolution/Evolution does something similar for
simple extensions, but has support for grouping (used for custom labels)
not enabled yet.

> > 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.

It might make sense to enable loglevel=4 permanently and increase
maxLogDirs to keep the most recent logs around. Then if something
unexpected happens, there is still a full trace of it.

> >         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).

Okay. I thought you had modified one of the supported properties and
that change did not make it across.

-- 
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.