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

[Srinivasa Ragavan <sragavan novell com>]

On Wed, 2006-12-06 at 00:51 +0530, Harish Krishnaswamy wrote:
> 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 agree with this. The backward compatibility with older GNOME
shouldn't be maintained in HEAD IMHO. This will also help to keep the
code pretty clean.

-Srini
> 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
> 
> 
> 
> 
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers