KConfig Bug?

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 26 June 2003 16:30, Ian Reinhart Geiser wrote:
> On Thursday 26 June 2003 10:13 am, Waldo Bastian wrote:
> > On Thursday 26 June 2003 15:13, Ian Reinhart Geiser wrote:
> > > Needless to say, for end developers there is no reason other than to
> > > build a backend that one needs KConfigBase, and from what I can see
> > > KConfigBase should go away asap.  Unless someone (waldo) knows of a
> > > VERY good reason why such an evil pair as KConfig/KConfigBase should
> > > exist together?
> >
> > KConfigBase provides the API, KConfigBackEnd the backend, and KConfig
> > provides storage and ties the two together.
>
> Well see this is where things get confused.  KConfigBackend relies on code
> that is only in KConfig, but can only be accessed in KConfigBase.    Worse
> KConfig provides the storage, with no knowledge of the backend, so we
> cannot safely move the storage to the backend where it can more effectively
> be cached.  Also storeing the config in the kconfig object ensures we will
> never be able to merge config backends without some expensive operations. 
> Unless we start to muck with the kconfig entry map.  I started down this
> route, but got stuck on a few issues of how to dirty only a single entry
> from the backend or from kconfig...   Really if only the backend had access
> to the entry map directly, or if the frontend didnt flush the whole thing
> when anything is updated, we might see an improvement.

I think the main problem is that the KConfigBackEnd API is not flexible enough 
for things other than file_based formats. That's hardly surprising, because 
only the INI backend has ever been developed, so design-requirements of other 
backend-styles have most likely never been seriously considered.

> > This gives you some design flexibility that allows for things as
> > KConfigGroup which implements the KConfigBase API, but shares the backend
> > and storage of another KConfig object.
>
> Im seening a greatly simplified API by just removeing KConfigBase and 
> keeping the storage in the backends.   The kconfig class is confused, it
> has no idea what its role in the mess is...  is it storage?  is it an
> interface to the configs?  is it both?  if so whats the kconfigbackend
> then? 

Storage and glue as far as I can see. 

> Maby im trying to over refactor it, im not sure.  But the orignal 
> intent of the API has long been lost, and IMHO its time to clean it up so
> we can get back to what it was orignally inteded to do.

I think the original intent of the API is described in KCONFIG_DESIGN. I think 
things have changed much since that was written.

> > I don't see any reason why it should go away. You say yourself that you
> > hardly ever use it as an "end developer", so why do you care about it
> > either way?
>
> I care becase im trying to fix it ;) Really no-one will ever notice when
> im done other than maby some speed improvement

Why do you expect speed improvements? I would only expect to see those if 
there is a fundamental inefficiency in the current way of doing things. If 
you are aware of one I would like to hear about it.

> and a reality of multiple backends.

That would be nice.

> One other side part im working on is better ways to keep 
> applications in sync with each others instances.

It would be nice if we could hash out the desired semantics for that. I think 
you need a deamon to do it efficiently and I guess you need some sort of 
locking semantics in the API towards the application.

I also wonder whether the syncing needs to be optional (on request by the app 
only) or not. From the application point of view, syncing basically equals to 
reparseConfiguration() being called automatically. Applications may or may 
not expect that, otoh KDE wide changes of styles / colors / etc. already do 
exactly that, so I guess it doesn't have too big of an impact.

> Currenly we do this silly 
> little tell everyone to reparse their config files via KIPC... while this
> approach is effective, its painful for things that use many config files...

But that's fundamental I would think. Using many config files is painful in 
and of itself and shouldn't be done if it can be prevented. The only other 
thing that we have some control over is to make sure that we report changes 
fine-grained enough so that we don't reparse config files unnecassery.

Otoh I know from my work on the theme manager that the biggest problem with 
for example theme changes isn't the reparsing of the config files, it's the 
updating of the widgets. The biggest problem was to make sure that the theme 
manager reported all changes at once so that all widgets where only updated 
once. If you end up reporting changes one by one (e.g. fonts have changed, 
color has changed, style has changed) applications end up updating their 
widgets way too often and you end up with a desktop that flickers for 5 
minutes (1).

So I think you have two requirements in this respect that are a little bit at 
tension which other: On one hand you want fine-grained change notification, 
on the other hand you want them to be atomic.

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com

(1) Well, maybe 10 seconds, but it felt like 5 minutes and I bet it could have 
been 5 minutes if my computer was slower and I had more windows open.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE++w7qN4pvrENfboIRAuz1AJsEn3KuHvlqCoURSPSZ+K9OYB8gpQCeLwwu
yah/kz1fQiZnvJxm4d3IrCw=
=JS+i
-----END PGP SIGNATURE-----