<br>On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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?</div></blockquote><div><br></div><div>Its GOA. </div><div><br></div><div>But one thing I like to mention here is that: v1 api endpoints are still working for calDAV & cardDAV </div><div>with basic http authentication (only for whitelisted applications, I suppose). For example,</div><div><br></div><div>"syncevolution --print-databases \ </div><div><span style="white-space: pre-wrap; "> </span>backend=carddav \ </div><div><span style="white-space: pre-wrap; "> </span>username=username@gmail.com password=****** \<span style="white-space: pre-wrap; "> </span></div><div><span style="white-space: pre-wrap; "> </span>syncURL=<a href="https://www.googleapis.com:443/">https://www.googleapis.com:443/</a> "</div><div><br></div><div>gives same default database as this:</div><div><br></div><div>"syncevolution --print-databases \ </div><div><span style="white-space: pre-wrap; "> </span>backend=carddav \</div><div><span style="white-space: pre-wrap; "> </span>username=goa:username@gmail.com \</div><div><span style="white-space: pre-wrap; "> </span>syncURL=<a href="https://www.googleapis.com/.well-known/carddav">https://www.googleapis.com/.well-known/carddav</a> ".</div><div><br></div><div>Here is the test setup for both (caldav): </div><div><a href="http://paste.ubuntu.com/6957096/">http://paste.ubuntu.com/6957096/</a></div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">With "it" you mean the Google web interface, right?</div></blockquote><div><br></div><div>Yes. Its Google Web interface.</div><div><br></div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"> 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.</div></blockquote><div><br></div><div>That explains everything. Also also from 1.4 release notes, its crystal clear:</div><div><br></div><div>"Instant Messaging information is supported by both sides with</div><div>different vCard extensions; the server stores these extensions without</div><div>showing the information, while SyncEvolution drops the data sent by</div><div>the server."</div><div><br></div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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.</div></blockquote><div><br></div><div>I think, I spoke too soon here. After reformatting local & remote databases I</div><div>couldn't able to reproduce the problem.</div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote> 4) If I change anything on "Bruce Banner" locally, log says changes
added but doesn't appear in Google(?).
</blockquote>
Again, logs with loglevel 4 would be more useful than the sync ouput in
the shell window.<br></div></blockquote><div><br></div><div>I attached the log. But I don't think further investigation on this is necessary,</div><div>as you explained, how some client properties ((CALURI, CATEGORIES, FBURL, GEO)</div><div>are not supported by the server (yet).</div><div><br></div><div>Thanks.</div>