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.

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);

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to