Moving KMail, KNode, Korn and related libraries to kdepim
schumacher at kde.org
Sat Jan 11 01:39:58 GMT 2003
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
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>
More information about the kde-core-devel