Hello! I have started integrating a patch by Chris Dumez which switches the SyncEvolution Evolution API from the legacy API to the new EClient API in EDS 3.2.
I'm currently testing it in the nightly testing, with EDS compiled from source on Debian Unstable. Backend is the normal file backend. I see one regression: when adding a detached recurrence with e_cal_client_modify_object_sync(CALOBJ_MOD_THIS), an EXDATE is added to the parent event. While semantically correct as far as I know (the detached recurrence overrides the EXDATE, instead of the EXDATE canceling out the detached recurrence), it is a side effect which makes it hard to undo the addition of the detached recurrence. Calling e_cal_remove_object_with_mod(CALOBJ_MOD_ONLY_THIS) won't be enough, the caller would also have to know that it has to remove the EXDATE. It also breaks SyncEvolution's automated testing: http://syncev.meego.com/latest/head-unstable-amd64/5-evolution/Client_Source_eds_event_LinkedItems_0_testLinkedItemsParentChild.log This seems to come from this code: e_cal_backend_file_modify_object() 8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2394) } else if (obj_data->full_object) { 8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2395) /* add exception for the modified instance */ 8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2396) e_cal_util_remove_instances (e_cal_component_get_icalcomponent (obj_data->full_object), icaltime_from_string (rid), CALOBJ_MOD_THIS); commit 8631a8f2e0c1ca71a48aeca5a44a11506ac77e33 Author: Milan Crha <mc...@redhat.com> Date: Fri Sep 2 13:21:07 2011 +0200 Bug #655253 - Delete of one occurrence of a repeatable event don't work This was added in 3.1.91. Milan, can you shed some light on why the patch solves #655253? I fail to see what e_cal_backend_file_modify_object() has to do with deleting one occurrence of a repeatable event. If the EXDATE was really necessary to avoid having the original and the detached recurrence show up, then IMHO adding the EXDATE only works around the real problem. The real problem is more likely to be in the matching against RECURRENCE-ID. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers