LinuxRegistry in Freedesktop & KDE

[C. Gatzemeier]

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[1].
>
> 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 
access control.

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

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. 
libtrash, ...)

Regards,
Christian