RFC: kservice -> kdecore?

[Avi Alkalay]

I'm not aware of all these KDE intrinsics.
But I applaude any initative to make KConfig-related classes more
lously-coupled.

Elektra developers had a bad time writing an Elektra backend to KConfig
because the interfaces and implementations could not be separated very well,
in semantics and in code. So what we saw is that KConfig is very tight to
the INI-file implementation.

Regards,
Avi

On 5/17/06, Aaron J. Seigo <aseigo at kde.org> wrote:
>
> hi....
>
> for kconfig having multiple backends, it makes the most sense to allow
> people
> to provide backends as plugins. the "natural" way of doing this is to
> query
> ksycoca for KService's that match, for instance, "KConfigBackend" as their
> type.
>
> of course KService is in kio, however. so this doesn't work. which leaves
> me
> with two options:
>
> a) do everything by hand in KConfig duplicating a lot of KService code
> b) move the essential KService stuff into kdecore alongside KSycoca*
>
> option 'a' is pretty unappealing. unfortunately, option 'b' ends up
> winding
> down a long dependency chain. it really gets nasty when KService makes
> it's
> one and only call into KServiceTypeFactory with:
>
>         t = KServiceTypeFactory::self()->findPropertyTypeByName(_name);
>
> KServiceTypeFactory relies on KMimeType ... and on and on... well,
> KServiceTypeFactory has findPropertyByName simply because it is where
> KSycoca's header is parsed out into a property dict. i'm thinking that it
> would be easiest to move this one bit of functionality into KSycoca to
> remove
> the dependency.
>
> that would leave a dependency on KServiceFactory due to 7 methods in
> KService
> that simply wrap KServiceFactory methods that are named exactly the same.
> typical example is:
>
>         KService::List KService::allServices()
>         {
>           return KServiceFactory::self()->allServices();
>         }
>
> deprecating these static functions in KService and requiring the use of
> KServiceFactory means no dependency on KServiceFactory.
>
> this would allow KService to moved into kdecore by itself with KSycoca
> (and
> various Qt classes) being it's only remaining dependencies.
>
> the downside to this is that KService and the KService "convenience"
> methods
> such as KServiceFactory end up in two different libs. but as it is KSycoca
> which is pretty key to all these things is already in kdecore and separate
> from kio.
>
> what are your thoughts? objections? better ideas?
>
> --
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060517/05943b4b/attachment.htm>