[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Avi Alkalay]

> I'm going to have to agree with George here. A single file is much
> easier for discovery of keys, not to mention the easing of names. 

Besides the issues, it is also better for security and symbolic links.



> For legacy software, of course LR does nothing, but the future software
> it can ease configuration and application discovery. The idea of a
> central way to store configuration in Linux is not new, as we can see by
> the name slinging of Gconf and the likes. I don't think any of the names
> we have seen are getting at the real question though, and that being not
> one of HOW, but of WHERE. It shouldn't matter what library a piece of
> software uses to read it's configuration or figure out the
> existance/configuration of other software on the system, but it should
> matter where that data is stored, and that it is stored in a
> standardized, predictable way so that integration and discovery can take
> place without large hacks. 

This is why i switched from Berkeley DB to plain text.
Regarding old software, yes, they have to be patched.




> Next we have editing, editing a config file happens irregularly, and
> often only at the beginning of an applications lifecycle. But you almost
> never edit a single line, you might disable one option to turn another
> on, editing almost always happens in pairs or greater. So the single key
> per file benefit is minimal, as the read overhead of 2 small files is
> pretty much the same overhead as reading a single slightly larger file.
> But, once again, the time spent editing a config is minimal when it
> comes to the lifecycle of an application, so again, we will call it a
> tie.

I'm working right now on this subject. We'll be able to do something like

   bash# rg vi system/sw/XFree

And vi will pop with an XML vision of your keys. Then you'll change and
save it, and rg will find what you changed, and apply it.


> The final time, application startup, is where the real meat and potatoes
> of config files is, and this is where a single file wins. Take an
> application like Apache or Xfree, split each option and section up into
> a single key per file, and you are looking at 100-300+ files to read in,
> which will take longer and be less efficient than a single relatively
> small file with multiple keys per file. Winner, multiple keys per file.

Yeah, for speed 1 file wins. But it happens only once per year (for
Apache for example).
And the benefit is that it is programatically much easyer to configure a
software 'getting' and 'setting' its properties, then 'sed' or 'ed' its
human readable text confuguration file. This is the point.


> I also believe that LR should start a dialog with the people at FD.O on
> the layout of a heirarchy for all to use and adopt, we need a standard
> location for configuration before we can work up a standard library to
> access those configurations.

This is a work to be done.

Thank you,
Avi

-- 
http://www.fastmail.fm - Sent 0.000002 seconds ago