[Kroupware] Re: [PATCH] Fixes Bug 49802: vcard does not get displayed, kmail shows error instead

[Don Sanders]

KMail and its dependent kdenetwork libraries need to be moved into 
kdepim. Those dependent libraries are mimelib and libkdenetwork (the 
later could do with a renaming). Other kdenetwork apps that also rely 
on these libraries should be moved into kdepim also.

This is because kdepim should be able to make independent releases, 
like KOffice, and the users should be able to get all there pim apps 
from one package.

Moving the KMail Part interface into kdelibs isn't a good solution, as 
it means pim users will end up having to update kdelibs to update 
kdepim, and that means they will end up having to update all of KDE.

Don Sanders / sanders@kde.org
KMail  Adopter / kmail.kde.org
KDE PIM  Co-founder / kdepim.org
KAddressbook  Founder / kaddressbook.org
KDE  Contributor / kde.org

On Thursday 28 November 2002 08:49, Marc Mutz wrote:
> On Wednesday 27 November 2002 22:33, Ingo Klöcker wrote:
> > On Wednesday 27 November 2002 08:11, Bo Thorsen wrote:
>
> <snip>
>
> > > I definately think kmail should be moved to kdepim. Stuff like
> > > this shows that kmail has compile time relations to pim while
> > > it has none to the other network apps (knode might be the
> > > exception). I understand that this has previously been decided
> > > against :-(
> >
> > In the past there were probably some arguments against moving
> > KMail to kdepim (like what?). But in the meantime the arguments
> > for a move, especially with respect to Kroupware and Kaplan,
> > clearly overweigh (IMO).
>
> <snip>
>
> Kaplan is designed to host several independent apps. Kroupware will
> be ported to this framework before merging. Thus, this argument
> doesn't count.
>
> OTOH, if you move KMail, you need to move libkdenetwork and
> mimelib, too.
>
> If you move libkdenetwork and mimelib, you need to move at least
> KNode and Korn. So you end up with a bloated kdepim and a bony
> kdenetwork. Not what I call a solution.
>
> Starting from bare C++ (abstract classes/interfaces) over Qt
> (QMetaObject) to KParts, we have a framework that encourages loose
> coupling between components. We should prove it's worth instead of
> going back to procedural "I want that code, so I need it at compile
> time" thinking. Wrong thinking. What you need is the interface (or
> not even that) and that can go into a common place such as kdelibs.
>
> Marc