Re: [Evolution-hackers] Install E-D-S backends into separate directories?

[Matthew Barnes <mbarnes redhat com>]

On Wed, 2011-01-05 at 13:17 +0100, Milan Crha wrote:
> are you sure they are kept in memory? I see the factory calls

Yes, GTypes are registered permanently whether the class is loaded
statically or dynamically.  This isn't about class instances.


> Do you mean you are returning from the backend module, apart of EBackend
> types, also different types in the eds_module_list_types() call? I
> always thought this function is mean to return only list of descendants
> of EBackend.

No, eds_module_initialize() and eds_module_list_types() are separate
functions.  eds_module_list_types() still only returns backend types.


> There is no need to have a separate module for calendar and book at the
> moment, it is only done this way. Separate folders may mean forcing this
> two-module model. On the other hand, if you share some parts between
> both, where I hope you do with Exchange, where both calendar and book
> backends are using same ESourceBackend type (or how you call it), then
> having one module may be a benefit.

The address book and calendar parts of Evolution-MAPI can share some
kind of ESourceMAPI class in libexchangemapi that holds configuration
details for the MAPI account.  I haven't got that far yet, but that's
basically what I'm doing for other backends.


> By the way, why cannot be ESourceBackend type registered only on the
> backend class creation? It's a similar way as Camel's provider does it,
> isn't it?

Both the backend factory class and the ESource extension types have to
be registered with g_type_module_register_type(), and the GTypeModule
isn't available from the class init function.


Here's the workaround I'm currently having to add to almost every
backend.  The lengthy comment explains a bit more technical detail.


void
eds_module_initialize (GTypeModule *type_module)
{
	/* XXX Because address book and calendar extensions are installed
	 *     to a common "extensions" directory, both factory processes
	 *     load all the extension modules.
	 *
	 *     That's fine for the factory classes.  Each address book
	 *     factory class registers its GType in e-calendar-factory,
	 *     but then the extension is unloaded and the address book
	 *     factory class is never referenced again.  No harm done.
	 *
	 *     Similarly, each calendar factory class registers its
	 *     GType in e-addressbook-factory, but then the extension
	 *     is unloaded and the calendar factory class is never
	 *     referenced again.
	 *
	 *     ESource, on the other hand, finds extension classes by
	 *     querying the GType system for registered descendants of
	 *     E_TYPE_SOURCE_EXTENSION.  Since GType registration is
	 *     permanent whether the GTypeClass is static or dynamic,
	 *     we only want to register the ESource extension in the
	 *     appropriate process.  So we check g_get_prgname()
	 *     before registering the ESource extension type.
	 *
	 *     The single extension directory design dates back to the
	 *     Bonobo era when we just had a single evolution-data-server
	 *     process.  Now that we've split up address book and calendar
	 *     services into separate processes, the "extensions" directory
	 *     should be split up as well.  But that will require an API
	 *     break in libebackend so the directory to load extensions
	 *     from can be passed in instead of hard-coded.  It requires
	 *     further public discussion before we do this. */

	if (g_strcmp0 (g_get_prgname (), "e-addressbook-factory") == 0)
		e_source_ldap_type_register (type_module);

	ldap_type = _ldap_factory_get_type (type_module);
}