XML/XSD based configuration files.

[Waldo Bastian]

On Tuesday 07 December 2004 16:38, Ian Reinhart Geiser wrote:
> 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.

Don't use KTrader. Set an environment variable that determines which KConfig 
backend to use and load it from $kde_moduledir

> 2) KConfig seems optimised for reading and writing entire files.  

Indeed.

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

There are two virtual functions in KConfig that take care of looking up and 
writing back entries. You can expiriment with those if you want to do per-key 
lookups.

> 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 ;)

I'm not sure I understand the issue, but I wouldn't want to support mixing 
different backends.

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

The problem is transfering the data from one process to the other. That will 
most likely involve some sort of marshalling and the time you need for that 
is in the same order as reading the file from disk. (Only the first time you 
read you hit the disk, the second time it tends to come out of the cache)

Now, the above only holds true for local files, if you have expensive 
cross-network lookups you may very well need some sort of local caching 
because the disk-cache of the OS no longer does that for you.

There are other advantages of having a central config server, so I think it's 
a worthwhile idea, but I don't expect to see much (any?) performance gain.

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041207/b9b62205/attachment.sig>