Ian Reinhart Geiser
geiseri at yahoo.com
Thu Jun 26 15:30:16 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
-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)
-----END PGP SIGNATURE-----
More information about the kde-core-devel