Proposal: New module "kdepimlibs"

[Matt Rogers]

On Tuesday 18 April 2006 16: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.
>

Is the ability to deviate from kdelibs policies and release schedules really 
that important? I could see this causing all kinds of problems, but I am a 
bit paranoid nowadays. :)

> 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?

I'm not sure that all of this belongs outside of kdepim. Are 
libkmime,libkholidays, and libsyndication already used outside of kdepim, or 
are we just putting them some other place so that other projects can use 
them? What happened to the rule that two apps had to be using a class (or set 
of classes) before a move to kdelibs could even be considered?

I think all the functionality of libemailfunctions can and should be moved 
back into the kdelibs as well.

My opinions, in summary:

- kresources, kabc, libkcal should definitely be somewhere other
  modules/software can depend on them. Whether that's kdelibs or kdepimlibs
- libemailfunctions should probably be merged into kdelibs somewhere.
- libkmime, libkholidays, and libsyndication have no justification for being
  in any module where other modules/software can depend on them, unless you
  can provide use cases for them.

Anyways, this is just my two cents. I'm not completely against the idea, but 
it seems like a solution looking for a problem to me.
--
Matt