[Evolution-hackers] RFC: Evolution's library requirements

[Harish Krishnaswamy <kharish novell com>]

Hi fellow hackers,

With reference to Bug 380534 on clarifying Evolution's library
requirements, I am putting down my thoughts and recommendations here and
will be proposing this in the weekly evolution meeting (#evolution-meet
on irc.gimp.org at 1000 UTC 6 Dec 2006) tomorrow. Comments/questions
welcome, as always.

I see two aspects of the problem described in the bug that merit two
separate approaches :

a. Inbound Dependencies - The libraries that Evolution/EDS/Evolution
Exchange depend on.
b. Outbound Dependencies - Dependencies that EDS libraries provides to
other applications that are based on or integrated with Evolution/EDS.

On (a) Inbound Dependencies, 

I suggest that on upstream CVS, Evolution  should depend on the most
recent stable versions of the libraries available in the corresponding
GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME
2.14). This is similar but not exactly the same as what Matthew has
outlined in Bug 380534. I agree that the configure scripts need to
hard-enforce these dependencies while building the packages.

I feel it is important that we move away from 
i) the use of deprecated APIs from various GNOME libraries to the
improved, maintained versions.
ii) Evolution specific widgets/thread/mutex/data structures
implementation that are now available in generic GNOME libraries. This
is possible now in some cases (EList->GList, EThread->GThread,
EMutex->GMutex?) but not all (ETable, ETree).

This ensures we take advantage of the newer capabilities available and
make it easier for contributors to continue adding value to our project.

However, it is also true that a very large number of our users
(enterprise, organizations, ISVs) still live on older GNOME Desktop
environments (Gtk <= 2.6), willing to upgrade specific applications
(Evo) but not their entire Desktop every six months. I think this would
be the case in future too that the 'majority' of the  installed base
stays a step or two behind the Bleeding-Edge/State-Of-The-Art Latest
releases.

If-defs and conditional compilations with significant addition to the
maintenance complexity are a necessity to support such users who need to
move to newer versions without overhauling their desktop. It is fair
IMHO, however, for individual distributions to handle them according to
their needs, rather than the upstream maintaining a super-set of
everybody's constraints. 

I wish to propose an exception to the above if and only if when an
inbound dependency is likely to cause a change to an outbound dependency
as discussed in (b).


On (b) Outbound dependencies, 
 and this is specially relevant to bugs like 373117, where we would like
to preserve the binary compatibility of outbound libraries (libebook and
libecal, in particular, which are the heavily used ones and as well as
various Camel/Calendar/Addressbook providers built on EDS) and take care
that any changes do not trigger massive upgrade overheads for those who
consume our libraries.  Evolution has learnt this the hard way, erred on
some and handled them with additional code overheads in other cases.

Here, I would recommend that we extend the APIs rather than
modify/delete them and mark the deprecated functions (to be discarded
after a specified and sufficient timeline) so that they do not get used
in newer code.  These libraries need to support older environments (and
possibly deprecated library calls) in a broader sense than in case (a). 
In these cases, some conditional compilation and #ifdef hacks will have
to be supported on the upstream as well. I wish I could specify hard
numbers on minimum dependencies for various libraries here. ( Is
'Libraries corresponding to GNOME 2.14' a good one ?) but I do not have
the answers yet. If you have a POV that you feel must be considered,
please do let me know or join us in the meeting tomorrow.
(There has also been a separate discussion on the need to get
Evolution's Camel library versioned and promise a compatible interface
for foreseeable future and Varadhan is already working on this with
other mail hackers).


I also feel the library dependencies are best conveyed by the build
tools and our decisions should be reflected in and enforced by our
pkg-config and configure scripts.  (remember the recurring NSS/NSPR ,
LDAP/NTLM issues ?) 
The Answer : Patch and Testing love [hint...hint ;-)]


Thanks,
Harish