Hello! As those who have tried the "google" config template know, only contact synchronization over SyncML works, because that is all that Google supports. Those who want to synchronize their Google calendar have to use third-party bridges to that data (ScheduleWorld, Goosync). http://bugzilla.meego.com/show_bug.cgi?id=319 A "native" solution would be to access the Google calendar via CalDAV. I gave that a try, using the Evolution Data Server CalDAV/Google backend as implementation of the protocol. In theory, this should have worked out-of-the-box with SyncEvolution, although setting it up would be fairly complex: * set up syncevo-http-server to access Google calendar * set up a client config to access the normal local calendar and syncevo-http-server * run command line with "--daemon=no", because that is currently the only way how we can have SyncML client and server on the same host In practice I ran into several problems which makes this approach unusable right now. For those who are interested in details, below is a description of the problems. My conclusion right now is: 1. We need a better solution for backend A<->backend B syncs (I sometimes call that "local sync"). 2. We should better write a CalDAV backend instead of relying on EDS. Not only will that avoid the issues below (which could be fixed), such a backend would also be useful for users not interested in running EDS and perform better. I'm assuming here that CalDAV has functionality that would helps us (like efficient listing of all items) which we can't use when going through EDS because it doesn't have corresponding APIs. Any CalDAV experts or volunteers around? The second task could be started already with the current code base. If no-one volunteers, then it'll end up on the backlog of feature requests. ------------------------------------------- Here's how I set up testing: * create two test calendars in Google * create the same calendars in Evolution, using Google_ical20_1 and Google_ical20_2 as names (naming expected by client-test, setting the evolutionsource property to the right caldav:// URL should work without creating the calendars in Evolution) * run CLIENT_TEST_EVOLUTION_PASSWORD=<password> CLIENT_TEST_EVOLUTION_PREFIX=Google_ ./client-test Client::Source::ical20 First problem: our test data uses a UID with special characters, because that happens to break "dumb" XML encoders/decoders and we want to find such issues. It also breaks the EDS backend. It can create such an event, but then cannot access it because the UID becomes of a URL used by WebDAV, and these special characters are not escaped there (seen in evolution-data-server console output). As a workaround, I simplified the test data to not use such a complicated UID when CLIENT_TEST_SIMPLE_UID=1 is set. Still no luck. client-test can create an item, but then retrieving it fails. The root cause for that is the backend's implementation of e_cal_create_object(). It should return the ID assigned to the new object, but for the WebDAV EDS backend it returns an empty string instead of the correct ID. Iterating over all objects later shows that the ID is something like http://www.google.com/calendar/feeds/<unique ID of calendar>% 40group.calendar.google.com/private/full/jjs14jjurojsoi7koo3op1vq3g Even if e_cal_create_object() worked, we wouldn't trust it in SyncEvolution, because it was broken in the past. From the code: // creating new objects works for normal events and detached occurrences alike if(e_cal_create_object(m_calendar, subcomp, (char **)&uid, &gerror)) { // Evolution workaround: don't rely on uid being set if we already had // one. In Evolution 2.12.1 it was set to garbage. The recurrence ID // shouldn't have changed either. ItemID newid(!id.m_uid.empty() ? id.m_uid : uid, id.m_rid); newluid = newid.getLUID(); modTime = getItemModTime(newid); m_allLUIDs.insert(newluid); } In other words, when a VEVENT has a UID, we use that as local ID. That's the best we can do, because the "garbage" really is a random pointer as far as I remember, so we cannot use it at all. -- 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.