On 3/4/06, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Saturday 04 March 2006 03:31, Clarence Dang wrote:<br>>  If one of these instances changes a config entry, the config change is not<br><br>change notification really is something that would be good to add. it's a<br>
little out of the scope of what i was hoping to do in this revision to be<br>honest, but discussion can't hurt (and maybe i get really motivated? kconfig<br>hacking is certainly not getting me laid, however ;)</blockquote>
<div><br>
Interestingly enough, that happens to be exactly the scope of what I'm planning on doing to KConfig.<br>
<br>
I'm an employee of Net Integration Technologies (see <a href="http://open.nit.ca">open.nit.ca</a>), and
I'm currently being paid to rewrite KConfig to use UniConf
(<a href="http://open.nit.ca/wiki/index.php?page=UniConf">http://open.nit.ca/wiki/index.php?page=UniConf</a>) in some form. <br>
<br>
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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">we could provide some sort of config daemon that all config read/write happens<br>through. done right this requires atomic commits and transactions. that's
<br>quite a bit to do.</blockquote><div><br>
Already done in UniConf.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">we could also have a daemon that simply coordinates writing: writes still<br>happen locally, but are notified of to a central process which then notifies
<br>the appropriate registered apps.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">or we could have kconfig itself emit dcop^Hdbus signals saying "i've written
<br>to this app". wouldn't take care of the "two apps writing simultaneously"<br>issue.<br>
</blockquote><div><br>
Notifications are already handled by UniConf, though there are many
possible ways to make use of UniConf's notifications for KConfig.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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). <br>
<br>
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()).<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">we can't really go the "cheap" route and simply watch the file(s) for changes
<br>in this case because config files will no longer be guaranteed to be single<br>text files in kde4 (multiple backends). so while this might work ok for INI<br>configs, it would probably work poorly with LDB. it would also suck because
<br>it would require reparsing the whole file rather than just updating the<br>sections that changed... *shrug*</blockquote><div><br>
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.<br>
<br>
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.  <br>
<br>
The example's I've mentioned so far are just some of the possible ways that UniConf could be used in KConfig. <br>
<br>
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).<br>
<br>
Essentially, my job is to do whatever it takes to convince you guys that UniConf is the future of KConfig.<br>
<br>
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.<br>
</div></div>