Re: [Evolution-hackers] Might be a generic ESourceExtension useful?

[Tristan Van Berkom <tristanvb openismus com>]

On 02/05/2013 04:01 PM, Milan Crha wrote:
> 	Hi,
> I was wondering, after the all stuff around ESourceExtensions landed in
> 3.5.x, the main disadvantage of it is code duplication, or passing
> unrelated stuff into one public folder just to have them available. It
> is, for example, when a backend defines its own extension, because it
> has some configuration, but the configuration part, which lands in
> evolution, also requires this extension, hence the code duplication.
>
> What about solving such issue with a generic ESourceExtension, which
> will provide similar interface like the GKeyFile (it is GKeyFile, after
> all), and the "clients" will be able to check for availability, read
> from or write to any section and key, thus instead of code duplication
> there will be set of "well-known" sections and keys?
>
> I thought there will be such a thing from the beginning, but Matthew
> chose a different approach. I think the generic extension would be
> useful. What do others think?

Hi again,

Milan and I brainstormed this a bit on IRC, and I just thought I'd
throw the ideas onto the list in the interest of moving forward.

Hopefully I'm not creating much duplication to his reply, as I already
started writing this mail I'll just send it with everything I already
had in mind to send.


Why Extension Specific API ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I currently like ESourceExtension APIs, it's nice to have real API
for this stuff because... well code looks prettier than working
with key files directly, and we can have nice pretty gtk-doc
generated for it etc.

But more importantly, while it's not an issue for many simple
configurations, ... having API allows us to elegantly handle
more complex configurations.

For example, ESourceBackendSummarySetup[0]


Binary Duplication
~~~~~~~~~~~~~~~~~~

In some cases ESourceExtension subclasses are added directly into
libedataserver... (see the libedataserver/ directory full of
extensions)... it's questionable if all applications linking
to libedataserver.la really require these additional extensions.

Code Duplication
~~~~~~~~~~~~~~~~

As Milan pointed out... some times extensions are defined in
subdirectories, some modules which need to communicate with a
given backend, for instance ESourceContacts[1] and ESourceContacts[2].

It would seem, duplicating this code in subdirectories is a way
to avoid the needless addition/bloat to the libedataserver API
where it could be shared.


I'm not sure what is the perfect solution, but we came up with
a couple of ideas.

Reduce code in ESourceExtension implementations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By adding some API to ESourceExtension we can remove all of
the GObject->get/set_property() implementations and property
declarations in the individual extensions... we can also
remove the per-subclass GMutex in favor of a single mutex
in the base ESourceExtension class.

An API such as:

   e_source_extension_class_install_config (extension_class,
                                            bool/int/string (enum),
                                            "config-name");


Could be used instead of all of the nitty gritty GObject property
handling repeated in each subclass.

ESourceExtension itself would then perform the management on the
protected memory declared by the subclass.

Subclasses could then use g_object_set/get directly in their
public APIs to access/mutate extension configurations.
(in this way we keep the ability to have pretty APIs and
complex configurations such as ESourceBackendSummarySetup[0]).


This could significantly reduce the impact of adding extensions
to libedataserver library directly.


CrackPot crazy idea of code sharing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To take it a step further... to address the aforementioned problems
of code duplication vs blowing up libedataserver's memory footprint,
we could address this at the build level.

All extensions could go into an 'extensions/' subdirectory, separate
modules/libraries/services which actually require the extension could
include the built object directly via Makefile.am (thus all extensions
would live in the same directory, be documented in the same place,
but at the binary level there would be no single library... the objects
would be compiled and used in various modules).

This is just a crazy idea... maybe someone can come up with better ?


Cheers,
         -Tristan


[0] 
http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-source-backend-summary-setup.c#n403

[1] 
http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/contacts/e-source-contacts.h?h=gnome-3-6

[2] 
http://git.gnome.org/browse/evolution/tree/modules/cal-config-contacts/e-source-contacts.h?h=gnome-3-6