LinuxRegistry in Freedesktop & KDE
C. Gatzemeier
c.gatzemeier at tu-bs.de
Fri Apr 16 17:25:02 BST 2004
Am Freitag, 16. April 2004 08:36 schrieb Duncan Mac-Vicar Prett:
> Searching for more technologies, made me land at the Linux Registry
> project (http://registry.sf.net), by IBM employee Avi Alkalay.
The reasons stated why we need some common access method are all very valid I
think. Unfortunately it may not work out to have everybody change to the same
type of registry-type storage, API etc..., it might not even be desireable
after all.
The "key-value" middlelayer[1] above the traditional /etc files (or other
backends (reiser4, interactive config server, or whatever)) can bring the
same benefits. The applications you want to configure may choose the backend
that fits their need best (say interactive gconf), they don't have to relay
on the middlelayer. However you could still configure this application
through the middlelayer. This allows smooth transitions between backends.
"Using the Registry, configuration file's syntax and handling
will not be a rework for each software."
I think this is adressing the fact that it is hard for config tools to track
format and option changes. But wouldn each applications need to be changed
and limit itself to only use the registry API?
The idea of CFG to address this is to have meta-config-definitions that are
maintainable separately from CFG. That way the system is easy to update by
meta-config-definitions that can even be distributed with the application
itself.
Another feature of the meta-config definiton is that it can define more than
just keys and value- types, -choices and -relationships. Applications
maintaining their own meta-config definitions get the benefit to easily have
a more better graphical configuration tool. It is possible to define forms
and wizard-logic for their config options. Frondends use those to provide
customized user interfaces beyond keys and values.
Cheers,
Christian
[1]
http://freedesktop.org/Software/CFG
Actually, KDEs KConfig XT seems to have some similarity, even though IIRC it
genrates source code from xml meta-definitions instead of a run-time
representation.
More information about the kde-core-devel
mailing list