Re: config system thoughts

[Elliot Lee <sopwith redhat com>]

On Wed, 21 Jul 1999, Havoc Pennington wrote:

> On 20 Jul 1999, Elliot Lee wrote:
> > 
> > We need string vectors.
> >
> 
> Is that distinct from list of string? 

Sorry, same difference. gnome_config_get_vector() :)

> > 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.

You are effectively trying to trade an infinite hierarchy composed of
directories/files/sections/whatever for an infinite hierarchy composed
partially of a directory and file, and partially in terms of data
structures inside the file.

You may not like the Applet_[123] approach, but terming it "a crappy hack"
without reason isn't exactly fair. It provides a simple, usable, and
accurate representation of the data in question, whereas putting all the
Applet_N stuff into a single data structure doesn't (the Applet_N stuff is
a section of the tree that the applet stores its config data in, not
something that the panel generates.)

More below.

> > >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.

CONFIG_PATH=file:/etc/gnome,file:~/.gnome

If I read a value from the /foo/bar/baz/bum path that is currently stored
only in /etc/gnome, and then try to write it again, it should be written
under ~/.gnome.

> > 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.

(Understood.)

> > 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.

The theme change notification is done through a separate X event anyways.

I personally don't want gnome-terminal updating all the terminals at once,
but it's possible that others might.
 
> 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.

I don't quite see what you mean here. Are you thinking GtkAdjustment-like?

There is a problem with GtkAdjustment of getting a changed signal, and the
signal handler gets

> So from an application's point of view, this is going to be invisible;
> the complexity is purely in the GConf implementation.

You are going to have applications with a constant connection open to
whatever centralized daemon you use to manage the events, plus the
performance hit of having to tell every single application about item
changes. This is a fair amount of overhead - tons of context switching,
communication, etc. - for a dubiously valuable feature. It also adds a
dependency on a centralized daemon, which makes GNOME that much more
fragile.

If we determined that a goal for GNOME applications was to have them
instantly reflect configuration item changes, then we would need to have
this notification somehow. However, it would take some pretty major
changes to applications to get them to do this.

Of course, you could just figure out a cute way to make it blindingly fast
and small, and then it is not an issue whether we have it or not. ;-)

> > >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 think forcing everything into complex data structures is going to make
things harder for the programmer, not easier. There's nothing hackish
about having a section of the tree that is used for a specific Applet or
whatever, and I don't think you could actually find a way to do the
gnome_config_push_prefix() and gnome_config_pop_prefix() stuff without
using a fully hierarchical item tree.

If you force people to use complex data structures to store all their
information, then you will effectively invalidate the usefulness of the
schema you proposed, because applications will just create their own
complex data structures to store all the interesting information, and a
generic config editor will become useless.

BTW, I just thought of another idea - it would be nice to be able to say
"give me a C data structure that represents this entire portion of the
tree" and then modify it using your program's internal routines, then push
it back out to storage with one function call. This might also be much
more efficient than the current "get, get, set, set, sync" model, and
perhaps would make transactions easier.

> > . 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?

No, but I can imagine there are cases where you'd want to add a new key
that isn't listed in the schema.

> > 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. 

Yes, but having two separate dataspaces makes things confusing for
programmers who want to use the new API to modify existing config items,
etc.

Sure, apps that use the gnome-config API won't get all the new features,
but I don't see that as a problem. The only issue is whether you can
successfully provide the GConf API with all the information it needs from
what is passed in a gnome-config API call.

> 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 don't consider code size as a really big issue, because it is shared
between all apps - it's more how much non-shared memory is used, and how
fast it is.

-- Elliot