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

[Srinivasa Ragavan <sragavan gnome org>]

On Wed, May 26, 2010 at 2:45 PM, Christian Hilberg
<hilberg 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
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
>
>