On Wed, May 26, 2010 at 2:45 PM, Christian Hilberg <hilb...@kernelconcepts.de> wrote: > Hi Matthew, > > On Tuesday, 25 May 2010, you wrote: >> Hi Christian, >> This sounds pretty cool and would be a welcome addition to the Evolution >> suite. > > Good. :) > >> On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote: >> > [...] >> I know of no other active Evolution/Kolab2 project at the moment. > > Well, then we're good to go. > >> [...] >> 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). > > Thanks for the hint. We'll try it that way then.
Look at MAPI design. Its way of organizing code, cache handlers which are good. Groupwise tbh wasn't designed/written the best possible way or it was done when the infrastructure was just being developed in parallel. -Srini. > >> > 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. > > We'll check that out with other Gnome projects. It may take some more research > on the project itself before we know how to actually accomplish the testing > stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing > framework. We'll check which method will impose the least impact in respect to > dependencies. Let's see whether there is some gnomish/gtk'ish/GLib'ish way of > doing testing which will be fitting for an Evo extension. > >> 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. > > autotools, 'make check' and friends will be the road to take, as far as I can > see right now. We'll take a closer look at the GLib testing framework to see > how much usable it is already. > >> > Connecting Evo and Kolab2 will most likely involve rather heavy use of >> > LibCamel infrastructure. Which Evolution version we will concentrate on >> [...] >> > 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. > > Hopefully, it will be possible for us to do it that way. We have just begun > our evaluation process, so lets see. Using the GLib'ified Evo code right from > the start would be wise. Anyway, we'll have to check whether we can afford > using Evo 2.30 / 2.31 as a code basis for our project... > >> 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. > > Phew, that's quite some time down the road. Our project is scheduled to show > usable results (i.e. installable packages which work as expected) within this > year. That means we might have to use a current stable version of Evo for now. > OTOH, it is also no fun to raise a project which is obsolete-by-design. We'll > have to meditate on that. > > Thanks for taking time to give us some useful hints! We'll be around. > > Best regards, > > Christian > > > -- > kernel concepts GbR Tel: +49-271-771091-12 > Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 > D-57072 Siegen Mob: +49-176-21024535 > http://www.kernelconcepts.de/ > > _______________________________________________ > evolution-hackers mailing list > firstname.lastname@example.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers