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

List:       kfm-devel
Subject:    Re: (kded/registries/konqy) Re: kdelibs/corba/kded
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-05-31 1:58:50
[Download RAW message or body]

Hi,

I get more and more the impression that shared mem is a good
way to go. It would mean that only KDE apps which really
want to start CORBA components need to link with libmico and friends.
All others just access the shared mem.

The biggest task to solve however, is to come along with semaphores.
And here comes our next problem:

If some app gets a semaphore and dies. Is the semaphore released
by the OS. I think som but we have to be shure.

When KRegistry is updating data, nobody may do reading.
A little problem is that we wont have a QMap etc in the
shared mem. That means we will loose this fast access.

About the mimetypes and services ( not the CORBA ones! ).
I have written some code for Kregistry which allows to
save the registry in a binary format. The code is still in, or ?

kded when first started creates KRegistry from the binary file,
updates it and writes it back if the update caused changes.
Whenever the KRegistry changes we write the binary back.

When a non CORBA app is interested in mimetypes, usual services
etc. it can just pull in this binary file and use it via libkio.
Most apps dont need to update their mimetype/service information
during runtime.

Even more lamer apps could still use something like kfmclient
to open some document or whatever.

That means we can serve everything except the power apps
without any CORBA. But power apps want to use full libkio
functionality, too.

SO: kded is responsible for
a) all CORBA services and activation of them
b) updating KRegistry and writing the binary file
c) sending diffs via CORBA.

c) means that powerapps like konqeror read the binary file
and connect to some kded event channel which informs about the
differences.

All that means: Use CORBA only where really needed.
Still fast startup since reading the binary is MUCH faster
than reading all kdelnk files and *.xpm files IMHO.
Even konqueror does not need to talk too much with kded
since it holds a always actual copy.

The problem with this approach is memory usage. I optimized
here for few CORBA and speed. How much memory does a full
filled Kregistry need ?

Bye
Torben


On Sun, 30 May 1999, David Faure wrote:

> [making public a discussion started privately for no particular reason]
> 
> > Torben wrote :
> > > David wrote :
> > > There is the problem of using KSharedPtr for services in kded - see kde-cvs
> > > and also :
> > 
> > KSharedPtr is buggy. I changed the semantics a bit. But have to fix
> > the code that uses it first. So where is your problem ?
> It has been fixed by using KSharedPtr in KServiceEntry.
> 
> > > In order to use kded in konqueror, query() is not enough.                      
> > > konqueror (in fact libkonq/kpopupmenu.cc) needs first to get                   
> > > the mimetype for a given URL. What are the plans about it ?                    
> > > We don't want to create the registry in konqueror, right ?                     
> > 
> > Would be waste of time and resources.
> > 
> > > Implement it in the kded idl ?                                                 
> > 
> > Seems like the right way, but: No.
> > I had problems with good old KFM to get mime type detection up to speed.
> > If Konqueror shows a dir with 500 files and makes 500 CORBA calls for
> > the mimetype stuff alone then our user might be pissed of because that
> > is slow. Kregistry can write a nice binary format of itself anyway. So
> > perhaps it would be better to load the in konqueror. Will cost memory
> > but will make things fast.
> 
> Well, what about splitting ?
> The _mimetype_ registry has to be loaded in konqueror, for fast browsing, sure.
> But the _applications_ (=services) registry is only needed when some
> application is started (popupmenu for instance), so konqy could ask kded
> for that matter.
> 
> > All other apps should indeed ask kded.
> At least CORBA-based apps. Linking to kded+corba just to have some
> mimetype info is too much IMHO (e.g. krn uses some mime-type stuff like
> kmimemagic, which is in kio, no need for kded)
> 
> > > (In this case, it looks like all other static methods of KServiceType/KMimeType
> > >  and KService should be implemented. Only static ones, since when we have a    
> > >  real object we can use it directly.)                                          
> > >                                                                                
> > > or ?                                                                           
> > 
> > May be. Since every function end every struct in IDL makes unbelievable
> > bloat I would suggest to implement as few stuff via IDL as only possible.
> > Most important of all: No convenience functions in IDL. We can still make
> > a wrapper around to make it easier to use. But the output of the IDL
> > compiler is reallllyyy big!
> Very good point. We'll remember it when designing IDL files.
> 
> > PS: I get the fealing that discussing kded design via mail is really a 
> > pain. What a pitty that KDE II is not in direct reach. Does anybody
> > of you come to LinuxTag in Kaiserslautern ? I assume not, or ?
> Alas not.
> 
> Using shared mem is also being suggested.
> I know nothing about it - seems powerful and rather complex, but
> is it available everywhere ?
> 
> My point is : if we keep the current design / way of doing things /
> then the solution is to load only the mimetype registry in konqy and
> use kded for services. If not I don't know.
> 
> -- 
> David FAURE
> david.faure@insa-lyon.fr, faure@kde.org
> http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
> KDE, Making The Future of Computing Available Today
> 
> 

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