Proposal: New module "kdepimlibs"

Wed Apr 19 16:34:05 BST 2006

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.

"sophisticated intra-module dependencies" is a nice description for this mess: 
http://www.deltatauchi.de/~vkrause/kde4/kdepim-dependency-graph.ps ;-)

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

Additionally, it's basically impossible to develop eg. a groupware resource 
outside of kdepim since not everything you need is installed (well, you could 
add your own comapt lib with the missing stuff...).

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

kdepim had the policy of depending on the latest stable version of kdelibs 
during KDE3, I'm not sure we can continue like this with a kdepimlibs module, 
although the need of kdelibs changes for kdepimlibs will be relative small if 
kabc and kresources are moved there.
I don't see this as a problem, but severeal kdepim people prefered to not have 
to update kdelibs regulary in the past.

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

libkcal currently depends on libkmime and ktnef (no idea why, I guess this can 
be resolved easily).

> - akonadiserver, libakonadi (the upcoming PIM Storage Service)

following the original design, libakonadi would consist of a core lib and type 
specific extensions (contact, calendar, mail, notes, rss feeds, ...) with 
dependencies to the corresponding libraries to handle these data (libkabc, 
libkcal, libkmime, libsyndication,...). So, it would be possible to put only 
a subset into kdepimlibs if this is wanted/needed.

I don't know if this will be possible with the backend (akonadiserver) as 
well.

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

not sure how much of libkdepim is left if you exclude classes that belongs to 
libkabc, stuff that was dumped there to share it between two pim apps but is 
of no general use and the forks of kdelibs classes.
However, there are some components like the KPIM::Progress* stuff which might 
be of general interest, but are not pim specific.

> - libsyndication (feed handling library)

this could solve the librss duplication in kdenetwork and kdepim

> - libkmime (email messages handling)

not sure if this is of general use

> - libkholidays (library for providing holiday information)

a must-have for the kicker clock-applet ;-)

> 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 really support this proposal, it would make the development of external pim 
apps/plugins/resources a lot easier. I think there's a reason why 
extragear/pim is quite empty...

However, there are a few problems we need to be aware of. While the newer pim 
libs code has been written with the library policy in mind, some of the older 
stuff has not. This means missing BIC prevention mechanisms, very few tests, 
partly GPL-licensed (some stuff is even GPL v2 only, which probably will 
become a problem anyway since this is incompatible with GPL v3). So, creating 
a kdepimlibs module is a lot more work than just moving stuff around and 
install all header files.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060419/1161e526/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/