kconfig and kde global config files

[Adam Sterling]

On 3/4/06, Aaron J. Seigo <aseigo at kde.org> wrote:
>
> On Saturday 04 March 2006 03:31, Clarence Dang wrote:
> >  If one of these instances changes a config entry, the config change is
> not
>
> change notification really is something that would be good to add. it's a
> little out of the scope of what i was hoping to do in this revision to be
> honest, but discussion can't hurt (and maybe i get really motivated?
> kconfig
> hacking is certainly not getting me laid, however ;)


Interestingly enough, that happens to be exactly the scope of what I'm
planning on doing to KConfig.

I'm an employee of Net Integration Technologies (see open.nit.ca), and I'm
currently being paid to rewrite KConfig to use UniConf (
http://open.nit.ca/wiki/index.php?page=UniConf) in some form.

I've been watching all the KConfig discussions on this list for a little
while, and figured that this would be a good thread to jump into and plug
what I'm doing. In fact, some of the ideas mentioned so far in this thread
are exactly what I'm looking at doing.


> we could provide some sort of config daemon that all config read/write
> happens
> through. done right this requires atomic commits and transactions. that's
> quite a bit to do.


Already done in UniConf.

we could also have a daemon that simply coordinates writing: writes still
> happen locally, but are notified of to a central process which then
> notifies
> the appropriate registered apps.

or we could have kconfig itself emit dcop^Hdbus signals saying "i've written
> to this app". wouldn't take care of the "two apps writing simultaneously"
> issue.
>

Notifications are already handled by UniConf, though there are many possible
ways to make use of UniConf's notifications for KConfig.

UniConf could simply be used to pass notifications about key changes, or it
could be directly checked (instead of a QMap) to get information about
groups/keys.

A seperate daemon could be used to sync info from the uniconf daemon to ini
files if that's desired, or the current method of applications using KConfig
to write the file directly (or through a UniConf generator instead) could
continue.

Because of the persistent daemon, UniConf even allows you to exchange a
little bit extra of memory usage for significantly decreased load time and
increased performance (after loading from ini files on first initialization,
the UniConfd can permanently store the keys in a table in memory).

For example, you could permanently store all the info from the ini files
after they are first loaded by a KConfig, and perform all the sync and
reparseConfigs in a seperate thread. Then, all  future operations on a
KConfig object (including the construction) will be ridiculously fast
(though you'd have give up the guarentee that the ini files will always look
the same as the KConfig's local QMap after calling sync()).

we can't really go the "cheap" route and simply watch the file(s) for
> changes
> in this case because config files will no longer be guaranteed to be
> single
> text files in kde4 (multiple backends). so while this might work ok for
> INI
> configs, it would probably work poorly with LDB. it would also suck
> because
> it would require reparsing the whole file rather than just updating the
> sections that changed... *shrug*


Well, if you really want to do it like that, UniConf could still help by
acting as an interface between a file watcher thread and the KConfig
objects. Most of the hard work is already done to make that possible.

Anyways, right now my only design requirement is that I use UniConf (It's
why I'm getting paid to do this :) ) to improve KConfig.

The example's I've mentioned so far are just some of the possible ways that
UniConf could be used in KConfig.

At this point, I'm wide open to suggestions on everything from features
(notifications, a centralized daemon, synchronization between KConfig
objects in multiple application instances, etc), to API details (how you'd
like to an app to add notifications or callbacks), to interesting "what if"
experiments that'd you'd like to see performed (like benchmarks on a KConfig
that uses a persistent, memory-resident backend, or a KConfig that leaves
the INI file IO to a seperate daemon).

Essentially, my job is to do whatever it takes to convince you guys that
UniConf is the future of KConfig.

If you don't believe it is, I'd love to hear why :), but I think the best
way to convince you will be to show you how much KConfig-based applications
can benefit, maybe even with no changes to the applications themselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060306/ee821afc/attachment.htm>