Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt

[Matthew Barnes <mbarnes redhat com>]

Hi Christian,

This sounds pretty cool and would be a welcome addition to the Evolution
suite.


On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote:
>   We have searched the web for information on similar projects and so far 
> found all of them in some kind of stasis or to be abandoned. In case we've 
> overlooked something and there is active development going on somewhere in 
> this regard, we'd be grateful to receive a pointer to the respective 
> project(s).

I know of no other active Evolution/Kolab2 project at the moment.


>   We aim to create a project which has good chances to go upstream. Plans are 
> to implement an E-D-S backend for Evo like the one for GroupWise. At the 
> moment I'm tasked with collecting information on how to do it "the Evolution 
> way" in order to improve the project's chances to go upstream.

We prefer backends for groupware servers to be packaged as a standalone
extension module for Evolution.  See for example evolution-exchange and
evolution-mapi (and I believe the GroupWise backends will soon be split
off similarly).


>   QA is one of the topics which will be stressed, so I was checking how unit 
> testing is done within Evolution. Skimming through the sources of Evo 2.28.3, 
> I found that there does not seem to be the "one specific way" of doing 
> testing, hence I would be interested in getting to know whether there is a 
> preferred way of doing (unit) testing.

We are woefully lacking an actively maintained and comprehensive unit
test suite and I don't think the project has yet matured to the point
where we even -have- a unit testing preference.  I'd recommend looking
to the broader GNOME community for best practices.

Mainly I think you want to integrate the tests into your autotools
framework (assuming that's what you're using) so the tests are executed
by running "make check" or "make distcheck".  In addition, GLib offers
some basic utilities for constructing test fixtures, though I'm not sure
to what extent that API has really caught on yet.


>   Connecting Evo and Kolab2 will most likely involve rather heavy use of 
> LibCamel infrastructure. Which Evolution version we will concentrate on is not 
> yet fixed, but reading the mailing list archives I found there is a lot of 
> change due to happen within this library. Although we might settle upon the 
> current stable Evolution (or even the Evolution version of some specific 
> stable Linux version, for a start), we would like to keep in mind that the 
> Camel API will change and internals like the type system will undergo some 
> major transitions. We would therefore like to avoid to writing code which will 
> be hard to port to newer Evo versions. Unfortunately, there does not seem to 
> be a "new developer's guide" which lists the pitfalls to avoid when writing 
> backend code for current stable versions of Evo which should later be ported 
> painlessly to newer versions of Evo. It would be great to be pointed into the 
> right directions here.

I'd strongly recommend targeting at least version 2.30, and if you're
that heavy on Camel and can withstand a little API churn, 2.31 would be
best so that you're using GObject from the get go.  Version 2.30 of both
Evolution and E-D-S was such a significant step forward from previous
releases that I've come to regard it as a generation gap.  Targeting a
release from an earlier generation will likely mean more pain down the
road when you finally have to cross that gap.

It's true that libcamel's backward compatibility guarantees have been
temporarily withdrawn until its API is sufficiently modernized.  The API
changes for 2.31 should taper off within the next month or so, then pick
up again once libgio gains support for transport layer security.

I'm guessing the Camel upgrades will be mostly complete by Evolution 3.2
next spring (assuming TLS support lands on schedule), and thereafter API
and ABI stability will be restored.