[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 23:36:07
[Download RAW message or body]

Hi,

On Mon, 31 May 1999, David Faure wrote:

> On Mon, May 31, 1999 at 03:58:50AM +0200, weis@stud.uni-frankfurt.de wrote:
> > 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.
> Yes, it seems great.
> 
> > 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.
> Every Unix has semaphores ??

Linux and DEC alpha have. It is at least a SysV feature.

> > 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.
> Unless we use the binary form of the registry in the shared mem ?
> Hmm seems dangerous...
> 
> > 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 ?
> Yes but right now it's buggy - core dumps on loading.
> Didn't find the time to investigate though.
> 
> BTW, I think that
> "load + isModified() + save" should put in a convenience method, in order
> to simplify the use of kregistry.

Good point.
 
> > 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.
> Ah, so apps using the registry don't 'save' it anymore ?
Exactly.
> Right it looks better...
> 
> > 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.
> If it's just about opening, sure.
> The use of libkio is for apps that want to do more
> (e.g. kmail displaying an icon for attachments)
> 
> > 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.
> Looks the right thing to do
> 
> > 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 ?
> .. to be measured.

Indeed. Did somebody do it ?

Bye
Torben

> 
> -- 
> 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]