[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:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-05-31 6:36:09
[Download RAW message or body]

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

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

> 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 ?
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.


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