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(a)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(a)gmail.com password=****** \
syncURL=https://www.googleapis.com:443/ "
gives same default database as this:
"syncevolution --print-databases \
backend=carddav \
username=goa:username@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.