The discussion around the Linux Registry (LR) proposal has mainly focused
on its performance and technical implementation. Discussions of these
kinds often tend to do that. (Another common theme: library
dependencies...)

What I think is interesting with LR though is how it tries to put all
configuration data in a single namespace. It is not alone in this. I think
GConf does this too, but in a different way. Why not abstract the
discussion for a moment and focus on the data rather than the storage?

Probably it is not realistic for all applications to share a configuration
framework in the short term. But a process that hopefully can be started
is to discuss a namespace, where configuration data can be referred with
XPath or similar syntax. For example, even though XF86Config is not xml,
its structure is hierarchical and can be broken down to a tree with config
elements. Each config key can be described with a key, which looks
something like "/Monitor/Monitor0/HorizSync/min"
(taken from the example that is described on the LR page).

I read a little about GConf, and it seems to works with hierarchical keys
too. "/apps/metacity/general/titlebar_font" is given as example. I don't
know how it works in KDE.

I guess a first step in the long process to a common configuration
framework could be to:

Define a common hierarchical namespace. Something like

/desktop/kde/...
/desktop/gnome/...
/desktop/common/...

Provide API in each individual config framework to let applications refer
to their config data with keys in this format. Encourage developers to use
these keys rather than any other way to fetch their config data. (Don't
work with files directly, etc). Put things that are agreed upon and can be
shared in the "common" namespace.

Then, over time, hopefully each config framework can be ported to a common
access mechanism, without affecting applications too much. Perhaps there
will never be a single storage format, but different to choose from,
depending on the situation. It can be implemented in everything from a
single XML file, to GConf, Linux Registry or LDAP.

I guess my point is that since a certain library probably not can be
agreed upon for a long time, use a common key namespace as API instead.

Claes