Re: [Evolution-hackers] Moving EExtension to libedataserver
On Wed, 2011-09-07 at 13:43 -0400, Matthew Barnes wrote: > On Wed, 2011-09-07 at 13:07 -0400, Matthew Barnes wrote: > > Once 3.3 development is underway, one thing I'd like to do is promote > > the EExtension framework in Evolution to libedataserver as a replacement > > for e-data-server-module.c. > > On second thought, libebackend might be a better place for EExtension > than libedataserver. Haven't decided yet, but it'll be one of the two. I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt branch on it? Indeed libebackend was the better place for EExtension. In addition, I created a few new classes in libebackend: EBackend EBackendFactory EDataFactory These new classes factor out some of the common pieces of their libedata-book and libedata-cal counterparts and serve as abstract base classes for them. Additionally, EDataFactory now handles all the module loading via EExtension -- completely replacing e-data-server-module.c. Obviously numerous API breaks here -- libebackend, libedata-book and libedata-cal are all affected. But it worked out to be a nice little API cleanup. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
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
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
