On Tue, 2014-02-18 at 23:33 +0005, Sunny Sigara wrote:
On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly
> 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
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 \
username=username(a)gmail.com password=****** \
gives same default database as this:
"syncevolution --print-databases \
The syncURL is effectively the same, because
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
> 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
"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
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
> 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
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
as you explained, how some client properties ((CALURI, CATEGORIES,
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.