KConfig Bug?

[Ian Reinhart Geiser]

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

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.

> 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?  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 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, and a reality of multiple 
backends.  One other side part im working on is better ways to keep 
applications in sync with each others instances.  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...  


BTW if im missing something obvious to a KConfig developer here, please let me 
know...   

Cheers
	-ian reinhart geiser

- -- 
- --:Ian Reinhart Geiser <geiseri at yahoo.com>
- --:Public Key: http://geiseri.myip.org/~geiseri/publickey.asc
- --:Public Calender: http://geiseri.myip.org/~geiseri/publicevents.ics
- --:Jabber: geiseri at geiseri.myip.org
- --:Be an optimist -- at least until they start moving animals in 
- --:   pairs to Cape Canaveral. ~ Source Unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE++wN5Py62TRm8dvgRAkWEAKCQ+nRjtKlVzYQsN6VXapdlsFK9vQCeOzA0
C9TgssBQauVIOWTQJApEL0c=
=Hp9d
-----END PGP SIGNATURE-----