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. _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers