On Tue, 2014-02-18 at 23:33 +0005, Sunny Sigara wrote: > > On Tue, Feb 18, 2014 at 12:51 AM, Patrick Ohly > <[email protected]> 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 \ > [email protected] password=****** \ > syncURL=https://www.googleapis.com:443/ " > > > gives same default database as this: > > > "syncevolution --print-databases \ > backend=carddav \ > username=goa:[email protected] \ > 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
