Moving KMail, KNode, Korn and related libraries to kdepim

[Bo Thorsen]

On Tuesday 14 January 2003 21:35, Dirk Mueller wrote:
> On Die, 14 Jan 2003, Zack Rusin wrote:
> > - smtp, pop3, nntp, imap4 slaves are being moved to kdelibs.
>
> eh, why ?
>
> We had them in kdebase, then they were moved to kdelibs, then to
> kdenetwork, and now back to kdelibs ?
>
> People, this "we move it around" has a cost, and its not small, and its
> unnecessary as well.

Please note with this that noone seems to argue that the right place for 
these slaves are in kdebase. That at least suggests that they're in the 
wrong place right now. ( <=Hidden invitation for people to speak up if 
they disagree )

There is a cost in moving, yes. But having code in the wrong place also 
incurs costs.

> It doesn't matter much where the kioslaves are, because they're not
> needed at compile time. They're only needed at *runtime*. The
> dependencies for *runtime* are the problem of the *distributors* who
> will probably split the stuff up anyway. Our CVS modules are far too
> monolithic to be usable for *users* (Classic example: who wants
> kpovmodeler just because he wants to use kiconedit?).

This is completely wrong! Right now a person who wants to use kmail with 
an imap account has to install arts, kdelibs, kdebase and kmail (even 
though he could trim this greatly by compiling from source). This way 
kdebase becomes a requirement for running some of the applications, which 
was *never* the way it was supposed to be. That it's not compiletime 
dependent is a fact that is given way too much weight by KDE people and I 
don't understand that - yes, it's very important not to go to the build 
mess of other big projects, but moving these slaves doesn't change 
anything in this area.

> so before we move it around yet another time, let me suggest to create
> a separate module for them. We can then map the directories into any
> module we want at a fixed, minimal cost. We should have done that years
> ago.

That would IMHO be a bad idea. The only thing you would gain from this was 
one more thing you need to install besides kdelibs. With this one, the 
ioslaves are better placed in kdelibs.

> The same probably applies to kmail, which could very well be its own
> toplevel module with all its branches nowadays.

The choice to move it to kdepim is much driven by kroupware and kontact 
and the fact that there is a lot of code dependency between the parts of 
what will be in kdepim after the kmail move. kdepim will is a module that 
consists almost entirely of very closely related apps now, and there is 
no gain from splitting it up.

My reasons for advocating the move of the slaves are:

- Noone seems to think kdebase is the right place
- Mail related slaves conceptually belongs with the mail program
- If you want to run the kdepim/kdenetwork apps, you're forced to install 
kdebase
- There is really only a single argument against the move: "They have been 
there for a long time"

With a project like kroupware_branch, the kdebase requirement really is 
annoying. IMHO it shows that it's wrong to consider runtime dependency as 
something less important than the compiletime dependency.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark