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

[Milan Crha <mcrha redhat com>]

On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote:
> 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. 

	Hi,
are you sure they are kept in memory? I see the factory calls
   e_data_server_get_extensions_for_type()
then frees this list with
   e_data_server_extension_list_free()
and finally calls
   e_data_server_module_remove_unused()
which may do the things you are trying to achieve by extension folder
separation, right?

I do not think it worth the change, the overhead on a factory load may
not be so large. Though see below.

> 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.

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.

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 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.

I suppose the other approach is to have some kind of hierarchical type
tree in e-data-server-module.c, having separated descendants of EBackend
and the rest returned from eds_module_list_types() and unload those
other types only if every EBackend types from that module are unused.
Is it more dirty way than overloading eds_module_list_types()?

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?
	Bye,
	Milan