Re: config system thoughts

[Havoc Pennington <hp redhat com>]

On 20 Jul 1999, Elliot Lee wrote:
> 
> We need string vectors.
>

Is that distinct from list of string? 
 
> I think going into more complex data structures is really overboard.
> Putting that functionality outside GConf (e.g. have a gnome-dentry routine
> for reading dentries, and perhaps providing decent GConf hooks to make
> this easy) will help make GConf be simpler and more robust.
> 

I agree it would be simpler; but consider the following problem. Say I
want to configure the printers on a system. What I really want is a
"struct Printer" which contains all the info about a printer.

If we already have hierarchical namespace, then composite types can be
implemented as simply a "directory" with a fixed set of files inside. Not
a huge deal... (famous last words...)

> How many existing uses of gnome_config have you looked at? I just did
> a 'tree -d ~/.gnome' and got three directories deep, and that's
> ignoring the two levels that individual files and sections within
> files add.
>

In all the cases of this I can find, this is caused by using "directories"
as lists, because there's no list type. I can think of uses for it though,
and I'm especially convinced by the prospect of implementing composite
types this way.

I don't think it's going to be so important if you can just store a list
though, instead of Applet_1, Applet_2, and other such crappy hacks.

> >Sources can be read-only or read-write with respect to a given user. 
> >If a config value is taken from a read-only source, then applications
> >will need to desensitize the widgets used to modify that value.
> 
> (This paragraph seems rather irrelevant - what the app does is its
> problem. In many cases the layering will mean that the value just gets
> saved to one of the read-write sources in the config path.)
>

Ugh, no. The user can't be allowed to change something if the change can't
possibly take effect! :-) Thus the paragraph.
 
> We also need to be able to define path aliases of sorts - e.g.
> 	systemwide/ -> /etc/gnome/
> 	per-user/ -> ~/.gnome/
> 	per-display/ -> ~/.gnome-`hostname`-$DISPLAY/
> 

Good idea. But the alias isn't necessarily for a file, but a general
"address" thing.

> Do you have some examples of where this would be needed? This adds more
> complexity and is almost a sidetrack from the main purpose.
>

Gtk themes, UI properties, all the times you'd send -HUP to a running
daemon, gnome-terminal should update all the terminals if you update one,
if the sysadmin updates the defaults for Netscape then all running
Netscapes should update, I think it's endlessly more nice.

But it adds wads of complexity, yes.

On the other hand, I think a config object that emits signals when a
property changes is a very nice way to structure application code, because
you can get try/revert for free, and you can also set config values from
multiple places in the code transparently. So from an application's point
of view, this is going to be invisible; the complexity is purely in the
GConf implementation.
 
> >Each key must be explicitly registered with the GConf system; on
> >registration, a short and long description of the key's purpose should
> >be stored. Also the key's type. It will then be an error to store the
> >wrong type in that key. The description can be used in generic config
> >tree browser/editor applications.
> 
> . How are you going to handle trees that have runtime-generated section
> names in them? E.g. the panel stores each session
>

I guess if we have hierarchical namespace, only the leaves have to be
registered like this.

But there's also the list type, I think most runtime-generated names are
bad hacks to get around the lack of one.
 	
> . I hope the requirement is not actually enforced on the programmatic
> level, even though it is a good idea. Making stuff inflexible is the road
> to a hated API ;-)
> 

Can you think of a reason you'd put two different types at the same key at
different times? That's just weird. :-)

> Ugh, this sounds sort of sucky. While obviously the first priority is
> getting the new API working period, it shouldn't be hard to redo
> gnome_config in terms of the new API...
>

Maybe. I'm not sure it gets us anywhere; the main point of a new API is
new features for apps to use, and by definition old gnome-config apps
don't use them. 
 
> I would also be interested in hearing how GNOME performance and memory
> usage will be improved (bloat is not an option! :) by switching from
> gnome-config to GConf.
> 

Um... no comment. :-)

Seriously, it is the same old functionality vs. size issue. I don't see
how to add features to gnome-config without using more code. I'm open to
the possibility that the features aren't worth it; we could just move to
XML and add file locking and be done with it.

By placing the backends in loadable modules, things would be kept pretty
reasonable though I'd think. The main backends would probably just be text
files or DB in a directory tree, so that's no big deal.


Thanks for the comments... I've changed my mind on several things now...

Havoc