On 3/7/06, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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 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.

<br>>  > that's quite a bit to do.<br>><br>>  Already done in UniConf.<br>><br>>  we could also have a daemon that simply coordinates writing: writes still<br><br>and slower than anything we could implement nativelly

</blockquote><div> 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).

<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;">>  > to this app". wouldn't take care of the "two apps writing

<br>>  > simultaneously" issue.<br>><br>>  Notifications are already handled by UniConf, though there are many<br>> possible ways to make use of UniConf's notifications for KConfig.<br><br>it makes zero sense to do kconfig -> uniconf -> INI in my opinion. to be

<br>perfectly honest, uniconf is exactly the wrong solution for cross desktop<br>issue and exactly the right solution for legacy.</blockquote><div><br>Actually, one possible usage of UniConf would be more like INI(or other backend)->KConfig(via a QMap)->UniConf. 

<br>Keep your backends if you want them, and UniConf can simply handle notifications.<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;">

>  UniConf could simply be used to pass notifications about key changes, or<br>> it could be directly checked (instead of a QMap) to get information about<br>> groups/keys.<br><br>please look at kconfig and consider the need for multiple backends. come back

<br>then and comment.</blockquote><div><br><br>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. <br><br>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.

<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;">>  For example, you could permanently store all the info from the ini files

<br>>  after they are first loaded by a KConfig, and perform all the sync and<br>>  reparseConfigs in a seperate thread. Then, all  future operations on a<br>>  KConfig object (including the construction) will be ridiculously fast

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

<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;">>  Anyways, right now my only design requirement is that I use UniConf (It's

<br>>  why I'm getting paid to do this :) ) to improve KConfig.<br><br>then ffs get involved with:<br><br>branches/work/kde4/playground/libs/kconfig<br><br>you want to create a kdeconfigbackedn subclass ...</blockquote>

<div><br>Looked into that, but unfortunately it's rather useless. <br><br>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. 

<br><br>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.

<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;">>  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. </blockquote><div> Not convinced eh? Didn't expect it to be that easy :).

</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>  If you don't believe it is, I'd love to hear why :), performance, flexibility, performance and the ability to decide our own fate.

</blockquote><div> 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.

<br><br>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.

<br> </div></div>