From kde-core-devel  Thu May 04 01:42:50 2006
From: Matt Rogers <mattr () kde ! org>
Date: Thu, 04 May 2006 01:42:50 +0000
To: kde-core-devel
Subject: Re: Proposal: New module "kdepimlibs"
Message-Id: <200605032042.50980.mattr () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114670688609997

k, a bit later than i planned, but better late than never, right?

On Wednesday 19 April 2006 03:51, Cornelius Schumacher wrote:
> On Wednesday 19 April 2006 02:08, Matt Rogers wrote:
> > Is the ability to deviate from kdelibs policies and release schedules
> > really that important? I could see this causing all kinds of problems,
> > but I am a bit paranoid nowadays. :)
>
> It's not the primary motivation for the proposal. But as the topic of
> releasing modules separately regularly comes up I mentioned it because we
> would be better prepared to handle it with the better modularization. I
> personally would prefer to not make use of this option.
>
> > I'm not sure that all of this belongs outside of kdepim. Are
> > libkmime,libkholidays, and libsyndication already used outside of kdepim,
> > or are we just putting them some other place so that other projects can
> > use them?
>
> libsyndication is a rewrite of a library which was forked from the
> kdenetwork module (where it's used by knewsticker) and duplicated in
> kdepim. It certainly would clean things up to only have one shared library
> for this specific functionality.
>

I wasn't aware of that. Definately nice to have it some place central then

> libkmime is a border case. Having decent access to email objects is
> something which could well be useful for lots of applications. Search
> applications are one example.
>

hmm, there's an app that i'm considering writing that would use kmime, so i 
think this would indeed be useful for lots of apps.

> libkholidays would provide all applications handling dates with the option
> to know about holidays. We are for example still missing the display of
> holidays in the calendar which is part of the clock applet. That's a pity,
> because it's a feature which would be easy to implement. The only reason
> it's not there yet is the problem of dependencies.
>
> > What happened to the rule that two apps had to be using a class (or
> > set of classes) before a move to kdelibs could even be considered?
>
> By having something like kdepimlibs it would be easier to follow these kind
> of rules because kdelibs would not be the only way to share libraries
> between modules, but there would be an intermediate step.
>
> > I think all the functionality of libemailfunctions can and should be
> > moved back into the kdelibs as well.
>
> For the specific case of libemailfunctions I'm fine with every solution
> where it can be folded back in an existing library.


Ok, so I'm totally convinced this is a good idea now. When's it going to 
happen and do I need to do something to help move it along? I've not seen any 
objections.

Thanks
--
Matt