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

[Cornelius Schumacher]

On Thursday 28 November 2002 14:08, Don Sanders wrote:
> On Thursday 28 November 2002 18:22, Cornelius Schumacher wrote:
> > On Thursday 28 November 2002 07:47, Don Sanders wrote:
> > > 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.
> >
> > In how much code would this result? What would be the size of
> > kdepim after moving KMail, its dependencies and the apps that
> > depend on that? How would this compare to other KDE CVS modules?
>
> So kdepim would become 37056 K, swapping places with kdenetwork to be
> the 3rd largest KDE source package I have. I think that's ok.

Agreed. It's not that bad as I thought it would be.

> > > 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.
> >
> > Distributions tend to split up the CVS modules for making packages.
> > So what the user gets isn't necessarily defined by the structure of
> > the CVS.
>
> Sure, but I don't see that as being significant. I mean this doesn't
> alter my thinking that kmail belongs in kdepim. I'm concerned about
> what KDE does, not what other distributors do.

You were talking about users and users get their packages from distributors. 
For users it simply doesn't matter where the source code is in CVS.

> The reason why kdepim
> was created was so that certain apps, like addressbooks, mail clients
> and organizers could all be put in the same package. Now that KMail
> has been made into a part and unified with its siblings it's just
> common sense to put it in the same package.

The whole point of KPart technology is to reduce dependencies between 
components so that it isn't neccesary to put all the code in one place.

But I agree that KMail would fit into kdepim at least as well as in kdenetwork 
and that we might get dependencies in the future which make this move 
necessary anyway.

> > As a developer you can update parts of kdelibs and you will have to
> > anyway because libkabc is in kdelibs. Making a separate release of
> > parts of kdelibs is certainly also possible, although it will
> > require some additional effort.
>
> These kind of dependencies are a hassle for users and they really
> should be minimized. I don't find the idea of a separate release of
> certain parts of kdelibs enticing.

Yes, but at least for libkabc this will be necessary, if you want to release 
something based on Kaplan before 3.2. We are planning some bigger changes to 
unify the Resource framework for addressbook and calendar data.

-- 
Cornelius Schumacher <schumacher@kde.org>