From kde-core-devel Wed Apr 19 14:39:34 2006 From: Nicolas Goutte Date: Wed, 19 Apr 2006 14:39:34 +0000 To: kde-core-devel Subject: Re: Proposal: New module "kdepimlibs" Message-Id: <200604191639.35702.nicolasg () snafu ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114545764827767 On Tuesday 18 April 2006 23:49, Cornelius Schumacher wrote: > 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) Cold kdgantt be part of it in some way too, to avoid the duplication in KOffice? > > 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? Have a nice day!