XML/XSD based configuration files.

[Ian Reinhart Geiser]

On Tuesday 07 December 2004 09:47 am, Waldo Bastian wrote:
> From the buzzword-department.
>
> See http://bugs.kde.org/show_bug.cgi?id=94611
>
> Anyone interested in looking into this? I most certainly do not want to
> *switch* configuration formats, but I think it's a viable strategy to offer
> an alternative configuration format to our users with great marketing
> potential.
The ability to swap out KConfig back ends is technically possible. I have been 
playing with the idea of a dbm based KConfig backend to store user config 
files (yes yes readable config files blah blah, our parser may be fast, but 
is it faster than not parsing at all? This i want to know.).

At any rate, basicly the rubbing points come down to this:
1) how do we make a plugin interface that can work to resolve and load plugins 
before kde is started.  I have had a big problem with this part because I 
don't understand KTrader enough to attack this.

2) KConfig seems optimised for reading and writing entire files.  This makes 
doing a sql/ldap/your mamas favorite directory server backends quite 
difficult.  Now this should be trivial to fix for KDE 4, and with a few minor 
adjustments KDE could have better support for things like NDS than Winders. 
Think KDE KIOSK + NDS based config objects with ACLS = Cross platform desktop 
control. Makes NTs profile management look like a real booger ;) I could also 
be missing ways of changing this behavior because the KConfig source is quite 
odd in the way things are broken up.

3) Once all of the merging takes place we need to chose a back end that will 
be the writer, since I don't see a good way to see the format of the key once 
it is merged.  This should not be much an issue though because ideally the 
user will be only changing local entries.  Globals would be the only corner 
case...  Its hard, but not impossible to have more than one back end merge 
its map with another one, but I don't have a clear idea on what the overhead 
of that would be.... I am assuming linear cause you have to iterate over the 
maps and insert the keys into the master map, not sure though ideally thats 
an implementation detail ;)

Now with wide eyes to the future there is another plan.  Zack and I have been 
kicking around the idea of using DCOP or some sort of IPC (xshm, dbus, your 
mamas favorite IPC implementation) to keep a central config server, and we 
can read entries individually from the service as we want them.  This would 
also make pushing out config changes trivial because we could push out 
individual keys.  I mean do we really need to parse kwriterc once for every 
text document I have open? I wont even count the rc files kdebugrc and any 
other global config files that EVERY kde application shares. If I anyone 
cares to throw out some banter on context switches feel free to show me a 
test case where the context switch is more overhead than parsing the files 
over an over again from a few separate apps.

At any rate this is my dribble... I am sure Waldo and David have some good 
answers for 1-3 and as for my plan, feel free to flame, I don't plan to 
debate it until its implemented.

Cheers
    -ian reinhart geiser

-- 
------(Ian Reinhart Geiser)-----<geiseri at yahoo.com>-----
The sun was born, and so it shall die, so only shadows comfort me...
-VNV Nation, Further