LinuxRegistry in Freedesktop & KDE
c.gatzemeier at tu-bs.de
Sun Apr 18 00:27:17 EEST 2004
Am Samstag, 17. April 2004 21:21 schrieb Avi Alkalay:
> > ... and so high level that it works with/over everything. Ethernet,
> > token-ring, ppp dial-up lines, radios etc. Please consider the
> > consistency layer being a little more high level, maybe like CFGs.
> I don´t know what are CFGs.
"CFG (Config4GNU) is a configuration framework (modular abstraction layers) to
represent and modify settings in arbitrary config files/databases"
Recognizing the many config files, it is hard to beleave they are all going to
go away in favor for a single format, not even in the long run. And "legacy"
systems want to be configured, too. Just think of the standard conf file that
can simply be sourced from a shellscript. I would imagine people be more than
hesitant when we tell them they should break that down and into some
registry. Honestly, I think it will just never happen. (at least not in the
free software world) So we should look for clever integrating alternatives.
I hope you'd find the time to read some more about CFG, when looking at both
CFG and LR I could even see a good application for both. As CFG just
generates a unified representation of the configfiles on behalf of the user
it also just relies on filepermissions for access control. Those are filewise
of course, and I think this is absolutly ok for most of the files in /etc
like basic system configs. This is another question for things that contain
user specific stuff. In this case it might very well be desireable to split
settings into different files instead of implementing another authentication
level, as it was originally poposed. In fact I would vote not to do that. You
see if you had support for the LR backend in CFG you could save any other
supported configuration file into the LR. On the common representation level
they look all the same, with CFG no app is forced to use a specific storage,
but when it eventally uses the CFG library funktions to access their
configuration data, I picture you could switch its representation node to be
saved in another backend say LR and now benefit from per setting grained
BTW: A 1:1 relation between keys and files might not be strictly necessary I
think, you could put options with the same permissions in one file, and
optimize maybe not only a lot of critisism away ;-)
> A solution for consistent application and machine
> configuration and integration is beyond the "desktop" and beloved KDE´s
I agree with you, that a good desktop solution should build on/be frontends to
good system solutions. (kio_fish vs. lufs/shfs/fuse, trashfolder vs.
More information about the xdg