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.