RFC: kservice -> kdecore?

[Aaron J. Seigo]

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060517/4e7aec21/attachment.sig>