Moving KMail, KNode, Korn and related libraries to kdepim

This message was posted to kde-core-devel mailinglist on January 10, 2003 by Ingo Klöcker

Dear developers,

the question whether KMail should be moved to kdepim has already arisen quite a few times on kmail@kde.org (and probably also elsewhere). Last week end at the Kroupware/Kaplan hack fest (cf. the Announcement on kde-core-devel on 21.12.02) we took the chance to talk about this from face to face. After weighing the pros and the cons we finally came to the unanimous conclusion that KMail and the corresponding libs (and therefore also KNode and Korn which also depend on those libs) should be moved.

The pros were:

• Less code duplication. Currently quite a few code is duplicated, e.g. kdepim/kalarm contains copies of kmime_* files which are actually part of kdenetwork/libkdenetwork. Furthermore all the KOrganizer KActions are duplicated in KMail and there is a second iCalendar parser in KMail which would become obsolete if KMail could use libkcal which is in kdepim. The problems of duplicated code could of course also be solved by moving some of it to kdelibs and introducing plugin interfaces, but moving KMail to kdepim means less work now and in the future.
• Reduction of dependencies between CVS modules. Although the dependencies within kdepim would become more complex at first, we expect that it will be easier to resolve this when the code is in one place.
• We expect the move to foster communication and cooperation of both developer groups and to be of benefit for both, KMail and kdepim.
• An email client is part of a PIM solution. And as we now have Kaplan it makes sense to put at least the most important Kaplan parts into one cvs module.

The cons were:

• The size of the kdepim cvs module will grow. (OTOH the total size of kdepim and kdenetwork will shrink because some duplicate files can be removed immediately after the move.)
• Danger of uncleaner interfaces. If applications are in the same module it's not imperative to make clean interfaces. We might be tempted to introduce some nasty dependencies e.g. between KO and KM just because it's so easy as they are the same cvs module.
• Danger of creation of a monolithic application. This is related to the second point. The counter argument to this and the second point is that the Kaplan framework forces the part developers to define clean interfaces. So this should prevent Kaplan from becoming one big fat swiss army knife application.

If there are no serious objections of developers which didn't participate in the Osnabrueck meeting, we will make the move at Friday, 17th of January.

Regards,
Cornelius (for KDE PIM) and Ingo (for KMail)

Participants of the hack fest:

• KDE PIM and KMail developers:
• Ingo Kl�ker (for KMail)
• Tobias Koenig (for KAddressBook, PIM in general)
• Daniel Molkentin (for Kaplan)
• Cornelius Schumacher (for KOrganizer, PIM in general)
• Günter Schwann (for KOrganizer group scheduling)
• from the Kroupware Project:
• David Faure
• Steffen Hansen
• Marc Mutz
• Bernhard Reiter
• Lutz Rogowski
• Bo Thorsen
• Karl-Heinz Zimmer

Additional note Jan 18th: KMail and co are now in kdepim.

| back to meeting overview |