Moving KMail, KNode, Korn and related libraries to kdepim

[Cornelius Schumacher]

On Saturday 11 January 2003 02:43, Allan Sandfeld Jensen wrote:
>
> The problem is that the next to go to kdepim would then be kopete (it
> is a personal communication program as well, isnt it?). The groupware
> features are so persuasive to use and integrate everywhere, that they
> need to be possible to depend on. That means moving parts of kdepim
> to kdelibs or making and extra module we can depend on.

I don't think that kopete has to go to kdepim. It fits well into 
kdenetwork. It doesn't depend on something in kdepim or duplicates 
kdepim code, or does it? The address book library is in kdelibs and I 
don't think that there is much need for calendar libraries in kopete.

Groupware functions that are useful for appications outside of kdepim 
will go to kdelibs, when they are ready. Most of this will be covered 
by generic DCOP interfaces or plugin interfaces, so that there is no 
need to create compile time dependencies and there is not much code to 
be moved to kdelibs.

Remember that the move of KMail to kdepim is done to solve concrete 
problems of code duplication we currently have. This is not about 
dreams for integration in the future but to solve the problems we have 
today. Moving KMail is the most easy solution which will keep us most 
productive.

Of course we could spend a lot of time on defining new general libraries 
and working out new dependency trees, and this would probably give 
cleaner interfaces and better modularized code, but at the moment there 
is just so much work to be done for kdepim and KMail that we think it's 
the best solution to make it as easy as possible to develop on kdepim 
and KMail and get all the integration work done which is still missing 
to get really useful groupware functionality.

> To get an idea of what I am thinking of, check the OEone homebase
> desktop or the many suggestion for a new kicker(slicker being one).
> All of these tryes to integrate outlook-like groupware features
> directly into the desktop with much succes. That's why I dream of a
> sort of kdepim, kmail
> (kdegroupware)-interface for checking for new email, appointments in
> the calendar (even new ones only received by email) and online status
> of friends/coworkers.

A lot of people share these dreams and that's the reason why so much 
exciting development is happening in this area right now. With the 
various variants of component technology of KDE and the designs and 
code which already exists we have a good chance that some of the dreams 
can be realized in a reasonable time. These will be modular solutions. 
In which CVS modules the code finally resides is only a minor detail.

> With the current CVS-rules these new innovative ideas can only come
> true if kdebase/kdenetworks and kdepim all moves to kdelibs and I
> dont think anyone really wants that.

As said before, with KParts, DCOP, plugins etc. we have technology at 
our hands which provides modular solutions without the need to put 
everything in one place. The move of KMail is a convenience thing to 
speed up development, as the groupware framework is just emerging. Once 
this framework is more mature it will be more easy to integrate other 
applications or functionality and it will not require to move much more 
stuff through CVS.

-- 
Cornelius Schumacher <schumacher at kde.org>