Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi Michael, On Wednesday 26 May 2010 at 12:18:04 Michael Meeks wrote: > Hi Christian, > [...] > It'd be better really to develop vs. master - from a support, testing, > future-proofing, and ease-of-use perspective. Presumably it is possible > to get you commit access to the repository so you can develop in the > repository [ when some code has been reviewed ] - it sucks to be stuck > out on a limb somewhere. We'd surely like to commit to the Evo repo. We're in the plannings still, but it is a request from our customer that our results be made public under GPLv2, and if possible, be accessible via the upstream project repo. We have some skeleton code which mainly serves to explore the wonders of Evolution right now and which we will turn into production code at some point. We will be working on the code with - as per present plans - five active developers. We're using our own Git repo for now, but it would be good for us to know that you people are willing to host us later on (that is to satisfy our funder's requirement). We'll develop our Plugin in a way that it will be a standalone one, just the way evolution-mapi is. Presumably, we will name it evolution-kolab. Shouldn't be too hard to transfer our own Git repo to your site. Is that okay with you? > Anyhow - exciting to see this get underway; hopefully it can also be > used as part of the Windows build - as a neat extra :-) We'll try to be as portable as possible, but our main target is Linux for now. Using GLib and friends wherever possible should prevent us from being totally Linux-specific, though. :-) Best regards, Christian PS: @Michael: sorry for the double posting, this should have gone to the list right away. -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
On Monday 07 June 2010 at 18:36:44 you wrote: > Hi, > [...] > I've used the GLib test framework extensively for one of my projects, > libgdata[1], and it's fine to use outside of the GLib/GTK+ trees. > Several GNOME projects make use of it (more than other test frameworks > in my experience). > The GLib test framework can fork() tests using g_test_trap_fork() and > friends. Note taken, thanks! :-) Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi, On Mon, 2010-06-07 at 17:31 +0200, Christian Hilberg wrote: > Hi there, > > while the project setup process is going on, I've had a look again at > suitable > testframeworks. Unfortunately, many unit test frameworks for the C language > appear to be abandoned. > > On Wednesday 26 May 2010 at 12:18:04 you wrote: > > Hi Christian, > > On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: > > > 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. > > I think the consensus from 10k feet is something like: > > any unit tests are good ! wow, you have unit tests ? cool ! > > :-) so it is unlikely that anyone is going to come and gripe about your > > unit testing framework per-se; of course people moan about new > > dependencies - so re-using the gtestutils.[ch] would be good if it's > > easy, and of course most preferably hooking it all up to 'make check' is > > best, as Matthew said. > > Using the GLib framework for testing seemed to be a natural choice, until I > dug through the mail archives and found that it > > (a) is neither nice to set up for projects outside GLib/GTK istelf [1] > (latest information I found on the issue dates back from 2008) > (b) nor is it well-documented and finally > (c) does not seem to be in wide use outside GTK and GLib itself. I've used the GLib test framework extensively for one of my projects, libgdata[1], and it's fine to use outside of the GLib/GTK+ trees. Several GNOME projects make use of it (more than other test frameworks in my experience). The GLib test framework can fork() tests using g_test_trap_fork() and friends. Regards, Philip [1]: http://live.gnome.org/libgdata > Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, > Embedded > Unit) did not receive project updates since 2006 (some since 2003), so I > assume they're dead. > Setting aside commercial frameworks, which are no option unless they're > explicitly FLOSSed, I'm left with > > Unity[2], Cutter[3] and Check[4]. > > Cutter depends on GLib >= 2.16, so I assume it uses the GLib testing > framework internally and I found references to it in some GTK/GLib context. > What's more, Cutter has support for GLib types (just read in the docs, no > practical experience as yet), which would be helpful in our case. > Check seems to be in wider usage. It fork()s a new process for each unit > test it runs, which seems to be a good thing to do to protect the framework's > address space from runaway test cases, unless you're so much restricted (as > in > some embedded environments), that you cannot fork() - but there is no point > in > running E-D-S in such an environment, anyway. > Unity (also) targets embedded contexts and the Sourceforge project is alive > (latest release 2009-12-07, current checkins to the SF repo). There does not > seem to be much of a documentation online. > > Long story short, as for now I'm down to either Cutter or Check to use. I'd > like to know if you prefer one over the other, which I would like to take > into > account for my proposal to the other project members regarding the > testframework to use. > > > Best regards and aTdHvAaNnKcSe for any insights, > > Christian > > > [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html > [2] http://sourceforge.net/apps/trac/embunity/wiki > [3] http://cutter.sourceforge.net/ > [4] http://check.sourceforge.net/ > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi there, while the project setup process is going on, I've had a look again at suitable testframeworks. Unfortunately, many unit test frameworks for the C language appear to be abandoned. On Wednesday 26 May 2010 at 12:18:04 you wrote: > Hi Christian, > On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: > > 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. > I think the consensus from 10k feet is something like: > any unit tests are good ! wow, you have unit tests ? cool ! > :-) so it is unlikely that anyone is going to come and gripe about your > unit testing framework per-se; of course people moan about new > dependencies - so re-using the gtestutils.[ch] would be good if it's > easy, and of course most preferably hooking it all up to 'make check' is > best, as Matthew said. Using the GLib framework for testing seemed to be a natural choice, until I dug through the mail archives and found that it (a) is neither nice to set up for projects outside GLib/GTK istelf [1] (latest information I found on the issue dates back from 2008) (b) nor is it well-documented and finally (c) does not seem to be in wide use outside GTK and GLib itself. Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, Embedded Unit) did not receive project updates since 2006 (some since 2003), so I assume they're dead. Setting aside commercial frameworks, which are no option unless they're explicitly FLOSSed, I'm left with Unity[2], Cutter[3] and Check[4]. Cutter depends on GLib >= 2.16, so I assume it uses the GLib testing framework internally and I found references to it in some GTK/GLib context. What's more, Cutter has support for GLib types (just read in the docs, no practical experience as yet), which would be helpful in our case. Check seems to be in wider usage. It fork()s a new process for each unit test it runs, which seems to be a good thing to do to protect the framework's address space from runaway test cases, unless you're so much restricted (as in some embedded environments), that you cannot fork() - but there is no point in running E-D-S in such an environment, anyway. Unity (also) targets embedded contexts and the Sourceforge project is alive (latest release 2009-12-07, current checkins to the SF repo). There does not seem to be much of a documentation online. Long story short, as for now I'm down to either Cutter or Check to use. I'd like to know if you prefer one over the other, which I would like to take into account for my proposal to the other project members regarding the testframework to use. Best regards and aTdHvAaNnKcSe for any insights, Christian [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html [2] http://sourceforge.net/apps/trac/embunity/wiki [3] http://cutter.sourceforge.net/ [4] http://check.sourceforge.net/ -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
On Wed, 2010-05-26 at 11:18 +0100, Michael Meeks wrote: > Hi Christian, > > On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: > > > This sounds pretty cool and would be a welcome addition to the Evolution > > > suite. > > Agreed. > > > 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. > > I think the consensus from 10k feet is something like: > > any unit tests are good ! wow, you have unit tests ? cool ! > > :-) so it is unlikely that anyone is going to come and gripe about your > unit testing framework per-se; of course people moan about new > dependencies - so re-using the gtestutils.[ch] would be good if it's > easy, and of course most preferably hooking it all up to 'make check' is > best, as Matthew said. > > > 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... > .. > > 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. > > Sure - the question is: what is your distro target, and timeframe to > ship ? are you going for RHEL / SLED / Ubuntu LTS ? or more community > focused distros ? > > AFAICS the latest enterprise desktops current in late spring will have > the underlying O/S deps necessary (GNOME 2.28) to build & run the code > as of now. Matthew / Chen - we have a general policy of not requiring > the latest & greatest platform until the next cycle right ? ;-) AFAICS gtk+ minimum version has been bumped and we had some reasons for that which could not recollect atm. Matt should be able to provide more information there.. We had been thinking of an option of using the latest stable evolution in enterprise releases once 3.0 is released, by installing the selected platform libraries which evolution requires in a different prefix so that other apps not affected by them. > > As such, it is entirely possible that if you want to ship and support a > product you will need to compile your own evolution, and e-d-s to ship > them [ hopefully the e-d-s calendar / contacts pieces that are used more > widely in the OS will still stay ABI stable ;-) ]. There will be no breakages there, though there might be some apis added.. - Chenthill. > > > 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. > > It'd be better really to develop vs. master - from a support, testing, > future-proofing, and ease-of-use perspective. Presumably it is possible > to get you commit access to the repository so you can develop in the > repository [ when some code has been reviewed ] - it sucks to be stuck > out on a limb somewhere. > > Anyhow - exciting to see this get underway; hopefully it can also be > used as part of the Windows build - as a neat extra :-) > > ATB, > > Michael. > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: > > This sounds pretty cool and would be a welcome addition to the Evolution > > suite. Agreed. > 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. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. > 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... .. > 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. Sure - the question is: what is your distro target, and timeframe to ship ? are you going for RHEL / SLED / Ubuntu LTS ? or more community focused distros ? AFAICS the latest enterprise desktops current in late spring will have the underlying O/S deps necessary (GNOME 2.28) to build & run the code as of now. Matthew / Chen - we have a general policy of not requiring the latest & greatest platform until the next cycle right ? ;-) As such, it is entirely possible that if you want to ship and support a product you will need to compile your own evolution, and e-d-s to ship them [ hopefully the e-d-s calendar / contacts pieces that are used more widely in the OS will still stay ABI stable ;-) ]. > 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. It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you can develop in the repository [ when some code has been reviewed ] - it sucks to be stuck out on a limb somewhere. Anyhow - exciting to see this get underway; hopefully it can also be used as part of the Windows build - as a neat extra :-) ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
On Wed, May 26, 2010 at 2:45 PM, Christian Hilberg 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 unsu
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
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. > > 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 GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi everyone. Presently, my company and it's associates are in the process of setting up an open source project to (among other things) integrate Evolution with the Kolab2 groupware server. The goal is to support as much of Evo's and Kolab's functionality as possible. 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). 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. 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. 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. Questions galore - any helpful input will be kindly appreciated. :) Best regards, Christian Hilberg -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
