Re: corba config caching

[Owen Taylor <otaylor redhat com>]

Elliot Lee <sopwith@redhat.com> writes:

> On Wed, 21 Apr 1999 quatt001@bama.ua.edu wrote:
> 
> [snip]
> > it (yet).  The Specs library (that's what I called it, but I may change
> > that eventually since I found out that RPM uses something called spec
> > files as well) contains a set of functions that let you get and set
> > configuration values without having to actually touch the config file
> > itself manually (similar to the way Windows has always done .ini files,
> > but with a few extensions).
> 
> This is what the gnome_config routines (which all GNOME apps use to access
> configuration settings) presently do.

This is not to say that gnome-config is the be-all and end-all
of config data. Some of the issues which we need to address
for GNOME:

Basic issues:

 1) Locking. This one is essential. Even on a single machine,
    we currently have problems when multiple programs access
    the same config key. 

 2) Configuration on multiple machines. Some parts of the GNOME
    configuration need to be shared between machines sharing
    a home dir (like the user's email address), some parts
    should not be necessarily be shared (like the panel setup).

Other issues:

 3) Network configuration. It would be very nice to be able
    to backend gnome-config with LDAP or ACAP.

 4) A richer set of data types. Trying to store "complex" data 
    into gnome-config gets really ugly. (Look at the gnome-session
    code if you want an example) - by "complex" I mean like
    a list where each element in the list has a couple of 
    attributes. 
   
 5) System defaults and overrides. Currently there is a simple
    system for this where gnome-config will look in a system
    directory before and after the user's .gnome, but there
    are no tools for maintaining such a setup, and perhaps
    there needs to be more levels (site-wide, and system-specific
    for instance)

 6) Documentation of config keys. This ties into the above.
    The preferences dialogs are just not good enough for a sysadmin
    to set up a system config - they don't allow fine grained
    control over what things get overriden, etc. I think there
    is a need for a tool like a "friendly regedit" where the
    sysadmin can go in and see:

====
    Background Color:  [BROWSE] [ ] override user's config     

    This configuration option set the background color of
    gnome-terminal.
====

    Think emacs customize mode. To do this, programs need
    to define the keys they are using, not just use them.
    I'd imagine there would be some central directory where
    each app would install a definition file for it's config
    data.

    Such a tool is not going to replace hand-written config
    dialogs, but could be a nice tool for the power user
    as well.

Preventing a system that handles all of the above from growing
into an unwieldy monster is the obvious challenge. 

I'm not sure if we want to bring CORBA directly into the
picture, but it seems like in the above the basic tasks
are defining data structures and writing data structures
out in a architecture-neutral, language-neutral fashion,
so perhaps some of the work of libIDL and libIIOP can 
be recycled in any case.

Regards,
                                        Owen