[Evolution-hackers] Install E-D-S backends into separate directories?
- From: Matthew Barnes <mbarnes redhat com>
- To: evolution-hackers gnome org
- Subject: [Evolution-hackers] Install E-D-S backends into separate directories?
- Date: Tue, 04 Jan 2011 15:00:38 -0500
When we moved E-D-S from Bonobo to D-Bus we split the address book and
calendar services into separate processes. But we're still installing
all the backend modules into a common "extensions" directory.
That means e-addressbook-factory is loading calendar backend modules and
e-calendar-factory is loading address book backend modules. Until now
that hasn't been a problem: the foreign backend classes are registered
but remain dormant.
On my account management branch I've started registering other GTypes in
eds_module_initialize() functions. For example, the LDAP backend now
registers both a backend factory class and an ESourceLDAP class which
holds all the LDAP account details and configuration options.
Without going into too much technical detail, suffice it to say this is
now causing problems with class loading and unloading via GTypeModule.
The cleanest and most obvious solution is to install the backends into
separate address book and calendar directories, then have each factory
process load from the appropriate directory.
This will require a few API changes to the backend libraries (if you
count pkg-config files as part of the API):
libebackend
-----------
- e_data_server_module_init() will take a directory path to load from
instead of using the hard-coded "extensions" path. This is the only
library API break, and shouldn't affect anything outside of E-D-S.
evolution-data-server.pc
------------------------
- Remove the "extensiondir" variable.
libedata-book.pc
----------------
- Add an "extensiondir" variable for address book backends.
libedata-cal.pc
---------------
- Add an "extensiondir" variable for calendar backends.
I haven't settled on names for the new directories yet but it doesn't
really matter much, as long as the "extensiondir" variables correctly
point to them.
If there's no objections I'd like to get this fixed in 2.91 even though
it's not currently causing any problems in 2.91, but just to get it out
of the way. I'll take care of updating the Exchange modules as well.
Matthew Barnes
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]