kconfig and kde global config files

[Adam Sterling]

On 3/7/06, Aaron J. Seigo <aseigo at kde.org> wrote:
>
> On Monday 06 March 2006 16:13, Adam Sterling wrote:
> >  > 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
>
> and slower than anything we could implement nativelly


Maybe. Maybe not. You certainly can't prove that. However, UniConf already
exists, while your "native" config daemon doesn't. UniConf has even been
rolled out on thousands of customer systems, and has had some serious
performance profiling done. If you really believe that you can do it faster
"natively", then so be it, but I find it hard to believe you'd be able to do
anything much more efficiently than UniConf (which is in itself a rather
strange thing to say, since UniConf is as much a protocol as an
application).


>  > 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.
>
> it makes zero sense to do kconfig -> uniconf -> INI in my opinion. to be
> perfectly honest, uniconf is exactly the wrong solution for cross desktop
> issue and exactly the right solution for legacy.


Actually, one possible usage of UniConf would be more like INI(or other
backend)->KConfig(via a QMap)->UniConf.
Keep your backends if you want them, and UniConf can simply handle
notifications.


>  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.
>
> please look at kconfig and consider the need for multiple backends. come
> back
> then and comment.



Not at all sure how that's relevent, though I'll have you know that I've
been though the KConfig code quite a bit recently.

As it stands now, the support for multiple backends isn't really there yet.
For a blatant example, you still have no way of deciding which backend to
use for which resources, though I saw that being addressed in a previous
discussion on this list, and the beginnings of that seem to be taking shape
in code. But that's just a start. Using an entry map to communicate between
the backend and the KConfig-using-application, isn't a very friendly idea.

Anyways, UniConf is a communication protocol, it is completely backend
agnostic. It is not a backend for anything in and of itself. If you want it
to store or retrieve its information in some format in some file, its pretty
trivial to write a generator to do so.

>  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
>
> except the overhead for sharing! we're already fairly fast in this case.


There are always trade offs. Anyways, my point is that you could make a
bunch of O(n) operations O(1). You could completely remove all config
related disk io from the KConfig object owning process, and stick into a
seperate daemon. Or not. It's hardly a requirement. But, it atleast has the
potential to be faster than what your doing now. Overhead can always be cut
down. How much memory would you sacrifice to keep all your kconfig info
resident in memory forever? Or maybe just some frequently accessed values?
Is a few megs of RAM worth a few seconds per day of faster UI response?
Somehow I don't believe that wiping the entire entry map, and then
re-parsing the ini's is the best way to go.

>  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.
>
> then ffs get involved with:
>
> branches/work/kde4/playground/libs/kconfig
>
> you want to create a kdeconfigbackedn subclass ...


Looked into that, but unfortunately it's rather useless.

As of now, there's no way to add a backend that will do anything but parse
some config info, and then sync all the info back into something. If the
backend can't directly see key set()'s, then it can't do notifications
properly.

Plus, the backend support will never be very useful unless you come up with
a better way of communicating with a backend than through an entry map. I
don't know if you've fully considered the implications of that choice when
you are dealing with large datasets and high latency/low bandwidth backends.
Heck, theres even an argument for using on-demand reading for all INI files
(or atleast for some other fs based file types).

To get around these limitations, I've even considered writing an
kconfigentrymap wrapper for a uniconfclient, because that's really the level
where it should be.

There are cases when you want to send all the data to the KConfig object at
once and there are cases when you want to do it on a key-by-key or
group-by-group basis, with or without caching. It should be up to the
backend writer to decide, since he knows best.

>  Essentially, my job is to do whatever it takes to convince you guys that
> >  UniConf is the future of KConfig.
>
> my job is to do what is best for kde. and in that scope, uniconf is not
> the
> future of kconfig. it is a future enhancement to it.
>

Not convinced eh? Didn't expect it to be that easy :).

>  If you don't believe it is, I'd love to hear why :),
>
> performance, flexibility, performance and the ability to decide our own
> fate.


Performance isn't just related to the number of layers of indirection
between pieces of code. If you can offload disk io to a seperate thread,
that should improve performance. If you can easily add backends that don't
just pass around their ENTIRE CONTENTS at once if you don't want them to,
that's good for performance too. Those are the sorts of things that I
classify as flexibility.

Sure, UniConf, in it's current implementation atleast, has sacrificed some
performance, in exchange for greater flexibility but the protocol itself has
no performance limitations. UniConf can be just a bit slower (if at all,
since in many cases it only adds one extra layer of calls between kconfig
and an efficient entry mapping) in the worst case, and immeasure-ably faster
in the best case (like handling thousands of entries stored in a network
attached database). But, UniConf can be easy extended to efficiently handle
any type of backend you can imagine, and KConfig can't. It has
notifications, KConfig doesn't. It can easily distribute the details of file
IO, and data storage to seperate threads when needed, KConfig doesn't give
you that choice. If you haven't noticed, most of those features I mentioned
were suggested by you earlier in this thread. The more you try to add those
kinds of features to KConfig, the more you are going to see KConfig start to
resemble UniConf in its abstractions, and its trade-offs.

As for deciding your own fate, that's why I love open source software. If
you don't like what I do to UniConf tommorow, take the code, add an
appropriate single letter prefix to the name, and stick it in kdebase. Judge
UniConf only by what it can and cannot do today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060307/6bde2a59/attachment.htm>