7:46 a.m.
Hi,
I was trying to sync evolution contacts with Google using syncevolution
on saucy.
1) First I created a single contact (i.e. Tony Stark) in evolution. Now
when I try to sync it syncs but not all the vcard fields.
For example, it completely ignores instant messaging fields.
LOG:
@default data changes to be applied during synchronization:
*** @default/gadb ***
after last sync | current data
removed since last sync <
EMAIL;TYPE=HOME;X-EVOLUTION-UI-SLOT=2
X-JABBER;TYPE=HOME;X-EVOLUTION-UI-SLO
X-SKYPE;TYPE=HOME;X-EVOLUTION-UI-SLOT
X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL
EMAIL;TYPE=HOME:tony.stark@ironman.co
X-JABBER;X-EVOLUTION-UI-SLOT=2:tony.s
X-SKYPE;X-EVOLUTION-UI-SLOT=1:tony_st
X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL
EMAIL;TYPE=HOME:bruce\,banner@gammala
added since last sync
-------------------------------------------------------------------------------
BEGIN:VCARD
N:Stark;Tony
:tony.stark@ironman.com
FN:Tony Stark
VERSION:3.0
X-EVOLUTION-FILE-AS:Stark\,
Tony
T=2:tony.stark@jabber.org
=1:tony_stark
OT=3:ironman
END:VCARD
-------------------------------------------------------------------------------
[INFO] @default/gadb: started
[INFO] @default/gadb: sent 1
[INFO @gcon] @gcon/gadb: started
[INFO @gcon] adding "Tony Stark"
[INFO @gcon] @gcon/gadb: received 1/1
[INFO] @default/gadb: normal sync done successfully
[INFO @gcon] @gcon/gadb: normal sync done successfully
Synchronization successful.
2) If I add a msn address in google-contacts & then run the sync, it
creates a duplicate in evolution/eds.
And even the duplicate doesn't have msn instant-messaging address.
LOG:
Data modified @default during synchronization:
*** @default/gadb ***
before sync | after sync
removed during sync <
added during sync
-------------------------------------------------------------------------------
BEGIN:VCARD
N:Stark;Tony
m
FN:Tony Stark
VERSION:3.0
X-EVOLUTION-FILE-AS:Stark\,
Tony
tark(a)jabber.org
ark
OT=3:ironman
END:VCARD
-------------------------------------------------------------------------------
3) If I create a new contact in google then sync, again it doesn't sync
instant messaging-fields.
Contact created in google (exported as vcf):
BEGIN:VCARD
VERSION:3.0
FN:Bruce Banner
N:Banner;Bruce;;;
EMAIL;TYPE=INTERNET;TYPE=HOME:bruce\,banner@gammalab.org
X-JABBER:bruce.banner@jabber.org
X-SKYPE:bruce_banner
TEL;TYPE=CELL:9999555555
END:VCARD
LOG:
Data modified @default during synchronization:
*** @default/gadb ***
before sync | after sync
removed during sync <
added during sync
-------------------------------------------------------------------------------
BEGIN:VCARD
N:Banner;Bruce
b.org
FN:Bruce Banner
TEL;TYPE=CELL:9999555555
VERSION:3.0
X-EVOLUTION-FILE-AS:Banner\,
Bruce
item1.X-ABLabel:Other
item2.X-ABLabel:Other
END:VCARD
-------------------------------------------------------------------------------
4) If I change anything on "Bruce Banner" locally, log says changes
added but doesn't appear in Google(?).
LOG:
screenshot: http://i.imgur.com/zSnR59w.png
While I don't expect to sync evolution related vcard properties (like
X-Evolution-Callback, X-Evolution-Radio), It should able to
sync normal vcard extensions.
Thanks.
11:21 a.m.
On Mon, 2014-02-17 at 15:51 +0005, Sunny Sigara wrote:
I was trying to sync evolution contacts with Google using
syncevolution on saucy.
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?
1) First I created a single contact (i.e. Tony Stark) in evolution.
Now when I try to sync it syncs but not all the vcard fields.
For example, it completely ignores instant messaging fields.
With "it" you mean the Google web interface, right? 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.
2) If I add a msn address in google-contacts & then run the sync,
it
creates a duplicate in evolution/eds.
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.
And even the duplicate doesn't have msn instant-messaging
address.
That's expected - SyncEvolution parses the vCard and only stores known
elements locally.
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.
While I don't expect to sync evolution related vcard properties
(like
X-Evolution-Callback, X-Evolution-Radio), It should able to
sync normal vcard extensions.
Yes, that's the goal. It's not there yet, unfortunately. I decided to
release SyncEvolution 1.4 anyway, because a limited sync may still be
better than none for some users.
--
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.
3:28 p.m.
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 ".
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.
1:26 a.m.
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.
2527
days inactive
2529
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Patrick Ohly -
Sunny Sigara