Re: Linux Registry, not only the issues side

[Havoc Pennington <hp redhat com>]

On Sat, 2004-04-17 at 09:54, Avi Alkalay wrote:
> I still would like to see GConf's numbers. XML is different.

I don't know if gconf is faster or not, but it doesn't really make any
difference; the reason for gconf's existence is not speed. And
discussion of ORBit dependencies or whatever sort of misses the point
too, which is overall design. You could change the dependencies, or the
file format, or whatever details you want.

My impression of the Linux Registry is that it's designed with
systemwide config in mind and does not do what we need for desktop
config, and of course gconf has the reverse problem (and is specifically
documented as unsuitable for systemwide config).

If you really want to get traction on this problem here are my
suggestions:

First the two reasons gconfd is a service not just a library:

 1. You need change notification. Suggest D-BUS for this.

 2. You need locking and transactions, especially with one 
    file per key (even gconf's one file per "directory" 
    causes lack-of-transactions problems).

More suggestions:

 3. http://www.gnome.org/projects/gconf/plans.html

 4. Documentation/schemas for keys is nice.

 5. There's an awful lot of desire to store config in LDAP.
    A story on how/whether to do this is good.

 6. In almost all cases a much bigger bang for the buck than 
    changing how configuration is done would be to eliminate
    configuration entirely:
       - autodetection and dynamic setup, e.g. of hardware
       - ensure the configuration is done once per type 
         or role of system in an enterprise, not once per
         physical system

It's also worth thinking about three kinds of data (from a desktop point
of view):

  1. Preferences

  2. Session state (open windows, their size, etc.)

  3. Documents

Recently my view is that your calendar and your email are documents;
i.e. they should appear to the user as a file that can be moved around.
This is in contrast to how Evolution currently works and how the above
gconf web site suggests it should work.

For systemwide configuration, we add a fourth kind of data:

  4. Systemwide configuration

A successful design I think has to have a story for all of these kinds
of data. Not all of them need to be handled in the same way. 

For example, perhaps documents should use something like GNOME Storage
(http://www.gnome.org/~seth/storage/). Or perhaps everything should use
Storage, who knows.

A question I think you should ask is whether it's worth compromising the
design for early boot; you may be able to do much better in the 90% case
by leaving the 10% case to plain text files.

Havoc