[Registry] Re: LinuxRegistry in Freedesktop & KDE

[George]

On Mon, Apr 19, 2004 at 05:15:38PM -0300, Avi Alkalay wrote:
> The LR's idea is to provide a consistent infrastructure to let creation
> of apps' configuration UI to be as easy as 1-2-3.
> I'm not talking about a simple KDE key editing tool, but a high level UI,
> application oriented, that will ask you human questions, like "Where is
> your HTML documents folder", and will change the correct keys behind. You
> don't have to know which key it is.
> 
> But, as advanced sysadmin you are, if something goes wrong, in extreme
> situations, you can manually lookup and edit the keys with vi.

In this case it doesn't matter if LR is the backend or we have the current
situation.  The gui needs to be geared towards the app anyway and thus it
doesn't matter if it parses the application config file, or uses LR, or some
other config backend.

If the actual storage method on disk only matters in extreme situations, then
you are attempting to solve only those extreme situations.

> > The majority of sysadmins I know would be perfectly happy to use some
> > form of cosy UI to do their day to day work, as long as they can hit the
> > real files when things go wrong.
> 
> Linux Registry was designed for them, as I cited above.

How does LR make any difference here?  See above.

> Read my first comment. But for that we need an applications ecosystem
> around LR, which is only the infrastructure.

So what is the advantage of LR compared to any other config system?  The main
solution here is the application ecosystem, but that does not depend on LR
existing at all.

> > Oh dear.
> > 
> > Firstly, it's trivial to code a parser for a simple key: value formatted
> > config file. Secondly, that code exists in those apps, and is very well
> > tested. Thirdly, the newer 'desktop' apps handle all this functionality
> > already, and do it through an API, so the code only exists once.
> 
> I disagree. Gnome has its own. KDE too. Samba also. The same for Apache,
> XFree, Mozilla, mount, init, wget, rpm, etc.
> Only in the above line we have 10 repetitions of the code that could be
> the same.

Yes There's code duplication.  And yes perhaps it would be nice in the
star-trek future to have the same code for it all.  But let's look at what
apps would have to do now:
  1) break existing installations by requiring a new configuration format.
  2) introduce a dependency on a new module that is not really used/installed
     on many systems.
  3) recode their config code.

(in order of severity)

Whereas keeping things as it is, keeps the applications working and they can
focus on say writing the GUI for editting the configuration.  Yes there is
code repetition, but this is trivial code in most cases.  This is not rocket
science.  Writing the configuration parsing code will likely take like 1% of
the time to design and write a good GUI for actually interacting with the
user.  There just doesn't seem to be any inscentive for either the people
writing the GUIs or the people writing the apps/servers to change.

> > Actually, you don't need to parse the Apache config file to do that. You
> > just need to write it, that's all. GConf, KConfig, ACAP, LDAP - all
> > these things can store the apache config for you, leaving the config
> > files intact for httpd to use, and allowing them to be used no matter
> > whether GConf is running or not. An experienced sysadmin with *no*
> > knowledge of any of these config systems can even deal with it if things
> > go wrong, and have the configuration system reparse the file.
> 
> With LR he can too.

But that's not a good argument for LR.  To have people change you need to
introduce some real significant advantage.

> Clearly, LR is not the solution for this. But providing a programatically
> easy way to change software parameters will make high level UI
> configuration software appear and consolidate in Linux distributions.
> This is a change on how users use the Linux desktop.

But LR is not programatically significantly any easier then many other ways
of doing things.  Why not GConf, why not KConfig, why not ve-config, why not
fopen/fgets/fclose.  Having done a lot with preferences code I think GConf is
by far the easiest to code correctly working GUIs.  The problem is the high
level UI.  There's only a finite amount of high level UI to do.  The solution
is to create that UI.

> This is an issue, but addresseable. Lets try to stop thinking in bits and
> bytes, and start thinking in thousands of users feeling Linux to be easy
> to use.

Yes, let's.  Then the correct solution is (pick one:)
  1) Write high level UIs to allow configuration
  2) Write a new API with low chance of getting accepted by say apache
  3) Scratch one's butt

Now personally I'm going to do 3, because I don't have any time for 1 and 2.
But I would argue that 1 would be get us to a world where GUI configuration
is available much quicker.

> By the way, adding to the customer's story above, the machine she bought
> to serve these 2MBytes total pages and images has a 76 GBytes HD. And
> BTW, she expects to start Apache (and read his keys) once a year, or
> less.

And why the hell then would she care if the UI for configuring apache used LR
or wrote the standard apache config file?  Also if memory/performance of this
are not an issue then why do the one file per key at all.  It seems the
argument for that is that it reduces the need to read keys you don't need and
thus somehow impact performance and/or memory usage.  If we want to have a
common config API/format, then why not pick one already in use and build on
that.  For example an .ini style format.  Then you note that a lot of
applications will already be using it and there will be less that need to
change.  It will reduce breaking of existing installations, it will reduce
the learning curve for people that already know the current config formats,
and it will reduce the code retooling of existing high level config UI.

> Please see my comments above.
> 
> I want Linux to change the world. Is not changing in the speed I was
> expecting.
> I believe one of the reasons are bad infrastructure concepts hinerited by
> old Unix systems.
> I designed LR to try to address some of them.

Perhaps, but LR as it is today has little chance of achieving the goal of
easy GUI configuration mostly because
  1) it doesn't add significant enough advantage for application writers to
     start using (they already have something, they'd have to change)
  2) changing to LR now has many drawbacks (not just performance, see above)

If you however make an API that reads writes most common current config
formats, then this API WILL make it easier to write high level config UI
without the drawbacks of change for the server applications.

George

-- 
George <jirka at 5z.com>
   Speech is conveniently located midway between thought and action, where it
   often substitutes for both.
                       -- John Andrew Holmes, "Wisdom in Small Doses"