The kdepim module has grown to an impressive size. After kdebase and kdelibs
it's the third biggest KDE module and it's becoming more and more complex to
work on kdepim because of the sophisticated intra-module dependencies.
Additionally there is some code in kdelibs which is closely associated to
kdepim in kdelibs (kresources and kabc). That this code is in kdelibs, but
other similar code like libkcal is not can only be understood by historical
To make things worse there is some code from other modules depending on kdepim
(e.g. the kbugbuster kresource from the kdesdk module) violating the rule
that modules shouldn't have other dependencies than kdelibs.
To resolve these problems I propose to create a new module "kdepimlibs" in SVN
which contains the major libraries from kdepim and the kdepim-related
libraries from kdelibs.
The new module would follow the same policies and release schedules as
kdelibs, and other modules would be allowed to depend on it. So it basically
would be a controlled extension and modularization of kdelibs to the pim
space, but by being a separate module we would also have a clear boundary to
deviate from the kdelibs policies or release schedules, if the need for this
arises. At the moment I don't see such a need, though.
The module "kdepimlibs" would tentatively contain the following components:
- kresources (the generic resource framework (this will be superceded by
Akonadi at some point in time))
- kabc (the KDE address book library)
- libkcal (the KDE calendar library)
- akonadiserver, libakonadi (the upcoming PIM Storage Service)
- libemailfunctions (the infamous attempt to create a shadow kdelibs under a
most obscure name and by highly dubious motives ;-)
- parts of libkdepim (general kdepim functionality)
- libsyndication (feed handling library)
- libkmime (email messages handling)
- libkholidays (library for providing holiday information)
I hope that a new module "kdepimlibs" will give us a cleaner modularization of
our code and make development easier and more efficient, especially in the
current KDE 4 times where due to the developing nature of the framework it's
often required to compile whole modules or at least well-defined parts of it.
What do you think?
Cornelius Schumacher <schumacher@xxxxxxx>
kde-pim mailing list
kde-pim home page at http://pim.kde.org/