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

List:       kde-devel
Subject:    Re: KConfig again - "resident in memory" format discussions
From:       David Faure <faure () alpha ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-05-16 20:25:57
[Download RAW message or body]

On Sun, May 16, 1999 at 04:12:59PM -0400, pbrown@redhat.com wrote:
> On Sun, 16 May 1999, Mario Weilguni wrote:
> 
> > IMO Steffan Hansen with his XProperty oder XRessource approach is right here.
> > Since the data from .kderc is pretty static and shared between all
> > applications, it's a waste to have it in application memory. 
> > 
> > XRessources
> > *  are portable
> > * can be shared to remote computers
> > 
> > And application-KConfigs are no good too, a registry is a much better approach:
> > * consistent view, shared between all running applications
> > * no memory overhead.
> > * can still be based on textfiles
> > * few runtime impact, since config-file entries are used SO seldom.
> > * less noise (harddisk!) when starting kde applications.
> 
> I agree that this is an intriguing possibility.  So we basically have two
> competing ideas:
> 
> 1. don't worry about data sharing.  Use a QCache to store the most
> recently used stuff from the KConfigs on a per application basis.  Use a
> QMap or a QDict (probably a QMap) for "dirty entries" which have been
> edited.  Flush it back out to disc at KConfig::sync() time.  Apps that
> just read some entries and then never use them again will quickly have an
> empty cache, thus wasting no memory.  Those that use them constantly will
> have them in memory, thus avoiding disc hits.
> 
> 2. Read KConfigs into memory at app startup time, and put them in some
> sort of shared space owned by the X server (i.e. XProperties).  This would
> be our in-memory registry.  It would be fast for small amounts of data
> (which config files typically are), network transparent, and very cool.

This solution looks very good for .kderc, because it contains global settings
that most apps (via kdecore & kdeui) need.
But isn't it too much to put the config for ALL applications in XProperties ?
Well, it probably takes the same space in X that it would take in the process itself.
Is that right ? (i.e. won't apps copy the values locally ?)
(if not, how long is it for an app to get a value from X ? Memory saving is good
but we have to think about performance as well)
And is there a limitation in the memory used by XProperties ?

And this solution is very dangerous since a X crash would lost the config changes,
wouldn't it ?

Sorry if this has already been answered, I'm a bit jumping in even though
I read the other posts...

> Something is steering me towards wanting to vote for #2. :)  It would be
> more of a paradigm shift than the first one, but it seems more cool and
> flexible.  Plus I'm willing to work on it, which is the most important
> thing I guess when we are getting a new piece of code off the ground.  All
> the talk in the world won't produce any code.
Sure.
But you seemed to be willing to work on #1 as well :)

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