Moving KMail, KNode, Korn and related libraries to kdepim

[Ingo Klöcker]

Dear developers,

the question whether KMail should be moved to kdepim has already arisen
quite a few times on kmail at 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 [1] 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)


[1] Participants of the hack fest:
KDE PIM and KMail developers:
- Ingo Klöcker (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030110/7a9d870d/attachment.sig>