[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RE: Re: KSycoca
From:       David Faure <David.Faure () CRAMER ! CO ! UK>
Date:       1999-10-19 8:23:22
[Download RAW message or body]

> > I think separating ksycoca and kio is 1) very difficult 2) useless.
> > (Everybody who needs one needs the other, they are very inter-related)
> 
> I don't really understand why this should be so, could you explain?
> I see KIO as an easy way to access URLs and to add new protocols, but
> I don't see any dependency on sycoca. The only reason I could possibly
> see is the need for dynamically registered protocols to be defined in
> the syococa config tree - is this what you mean?
> 
> > 
> > So ksycoca/ contains a replacement for kio (kio_* untouched, but all
> > the rest ported to sycoca).
> 
> Could you expand a bit? I thought I understood what sycoca was doing,
> but I guess I'm missing something.

The idea of splitting isn't new : I had it in Erlangen and since then I've
tried
twice (!). But for the reasons explained below, it's not only very difficult
but also useless.

KSycoca, and why it's part of libkio.
=====================================

KSycoca is the new implementation of what was previously called KRegistry.
It allows apps to get directly hold of mimetypes, servicetypes and services
(no need for IPC with kded anymore). Internally, it uses a binary database
file
with streamed objects and all sort of indexes for fast lookup (hash tables
for indexes by name, index of offers by servicetype, and soon, maybe, index
by 
filename mask). And kded is the one that writes out that file.

KServiceType, KService and KMimeType contain the API for the user
applications
(the sycoca stuff, factories, etc.. are hidden behind).

BUT :
As before, KMimeType and its descendants (KDEDesktopMimeType, for .desktop
files, ...)
as well as KService, contain the code to be able to RUN themselves. They're
not only providing information, they're providing functionnality as well.
To run, they need KRun which in turn needs KIOjob.

If you're thinking : fine, let's make ksycoca use libkio, that's wrong since
libkio needs to be able to get mimetypes/service information...
One proof among others :
kio_cache.cpp:      KMimeType* mime = KMimeType::findByURL( u, 0, true ); 
And if you're thinking : fine, let's make libkio use ksycoca, then all the
'run' stuff
has to be moved out of kmimetype.

And the point is that even we find a way to split those libs, I 
really don't see the point. Apps that need one part need the other part.
What's the point in getting a mimetype or service information and not 
being able to run it ?
Splitting and then seeing all apps linking both is just a waste of time.

Finally, libkio, even when I'll move canossa's trader into it, has approx.
the same size (in terms of source code I mean) as libkdecore or libkdeui. 
A standard complexity for a KDE 2.x library.


Now, some good news : ksycoca is almost ready. Its TODO file contains all
that
still needs to be done before the switch. Feel free to contribute, with
code, ideas, or testing :)

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramer.co.uk - Cramer Systems

[prev in list] [next in list] [prev in thread] [next in thread]