--nextPart9473288.22OqGRbri5
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 me=
ss:=20
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 historic=
al
> 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 t=
he
> rule that modules shouldn't have other dependencies than kdelibs.

Additionally, it's basically impossible to develop eg. a groupware resource=
=20
outside of kdepim since not everything you need is installed (well, you cou=
ld=20
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=
=20
during KDE3, I'm not sure we can continue like this with a kdepimlibs modul=
e,=20
although the need of kdelibs changes for kdepimlibs will be relative small =
if=20
kabc and kresources are moved there.
I don't see this as a problem, but severeal kdepim people prefered to not h=
ave=20
to update kdelibs regulary in the past.

> The module "kdepimlibs" would tentatively contain the following component=
s:
> - 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=20
be resolved easily).

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

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

I don't know if this will be possible with the backend (akonadiserver) as=20
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=20
libkabc, stuff that was dumped there to share it between two pim apps but i=
s=20
of no general use and the forks of kdelibs classes.
However, there are some components like the KPIM::Progress* stuff which mig=
ht=20
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 modularizati=
on
> 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 framewo=
rk
> it's often required to compile whole modules or at least well-defined par=
ts
> of it.
>
> What do you think?

I really support this proposal, it would make the development of external p=
im=20
apps/plugins/resources a lot easier. I think there's a reason why=20
extragear/pim is quite empty...

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

regards
Volker

--nextPart9473288.22OqGRbri5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBERlh8f5bM1k0S0kcRAk1fAKCvZNhTNXl7TjJUOAkzXV401pIBXQCeLWmN
+NHQpChoNVja4Ztjd6peCeY=
=4oBr
-----END PGP SIGNATURE-----

--nextPart9473288.22OqGRbri5--