[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-06-01 0:20:41
[Download RAW message or body]

Hi,

On Mon, 31 May 1999, Simon Hausmann wrote:

> On Mon, 31 May 1999 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, sounds nice.
>  
> > 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.
> 
> hmpf, always these worst-case scenarios... ;-)
> 
> AFAIK using SysV style semaphores (semget,...) leads to such a leak :-(
> So I guess we'll have to go the use-filesystem-mmap-style of sharing
> memory and locking the file via fcntl.
> Or?
> 
> > 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 ?
> 
> Yes, it is.
> (though the last time I tried it it crashed)
> 
> > 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.
> 
> Yes, it does so already :)
>  
> > 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.
> 
> But: Kded saves the updated kregistry binary file only when shutting down,
> so apps will always read the old registry, until kded gets restarted and
> flushes the binary file.
> Or?

Hmmmm, saving it on every change with some seconds delay to catch
multiple parallel changes is too slow ?

> > 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.
> 
> This sounds like an interesting approach.
> 
> > 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 ?
> 
> That's really a problem IMO. I mean a registry can become really big if
> you have lots of .desktop files installed.
> I'd love to find a way to have the registry in shared memory.
> 
> <wild_guess>
> Perhaps we can share the binary registry file via mmap in some way?
> So that kded puts any updates directly into this file, which is shared
> among all clients (read-only) .
Speed ?
> </wild_guess>
> 
> <even_stronger_wild_guess>
> Perhaps this could be integrated into libkio, so that the registry as is
> does not exist in the usualy way anymore but instead as binary data block,
> which is read by client functions and managed (written) by server
> functions (called from kded) . This way we'd have one single registry in
> the whole system, which always reflects the "real" registry in applnk with
> all its .desktop files
> </even_stronger_wild_guess>
> 
> ...just guessing ;-)

You are ack on a general approach. IMHO we have to distinguish between
apps which need ALL informations about something and apps which
need SOME/ONE informations about some Topic.

Konqueror: ALL mimetypes, ONE/FEW infos about services at a time
KMail: The same
Kded: ALL services
kpanel: Like konqueror.

So what do we learn ?

IMHO: Services can be accessed via CORBA or kfmclient like stuff since
I dont know a app which needs ALL infos about ALL services very fast.
Only Kded needs that.

The stuff that many apps need ALL infos about os the mimetypes
and corresponding icons stuff. So we should try to optimize that.

Simple way: CORBA. To slow to get ALL informations.

IMHO we can focus on the discussion how to get infos about ALL
mimetypes/icons and how to do fast kmimemagic stuff.

Since mime types may change, we need a central app which looks
at the changes -> kded ?

Bye
Torben

> Ciao,
>   Simon
> 
> --
> Simon Hausmann       <hausmann@kde.org>
> http://www.kde.org/  <tronical@gmx.net>
> 
> 
> 

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