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 reasons. 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