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 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers