Re: config system thoughts

[Havoc Pennington <hp redhat com>]

On Wed, 21 Jul 1999, Elliot Lee wrote:
> 
> 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.)
>

I may agree with you. I'm almost convinced anyway. :-)
 
> 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.
>

Maybe an application could do this, but the user shouldn't be able to,
because the app's state wouldn't change (/etc/gnome would necessarily
override ~/.gnome, making ~/.gnome irrelevant). 

It would be way weird to change a value, click "apply", and have nothing
happen.
 
> 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
>

If you have your GConf object, which emits "changed" when a value changes,
you can attach a "changed" callback which actually modifies application
state to reflect the config. Then your property box just sets config
values, "changed" is emitted, and your app updates. If another app changes
the config values, your app updates in the same way.

I'm not sure we want a single "changed" signal and not sure we'd use
GtkObject, because of efficiency issues (you don't want to have a long
strcmp chain to switch on the config key), but you see what I mean maybe.
 
> > 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.
> 

Agreed. It's a pain.

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

I'm thinking. Send suggestions. ;-)

> I think forcing everything into complex data structures is going to make
> things harder for the programmer, not easier. 

This particular feature is really intended to make things easier for users
and packagers, rather than easier for the programmer :-)

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

I agree here now.
 
> 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.
> 

That's a nice idea. Could be merged with the concept of a change set, so
you can prepare a change set then commit it or revert it.

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

Right. The schema doesn't prevent that, it just requires you to register a
description of each key.
 
> 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.
> 

Sure enough.

Well, the notifier/listener stuff is the primary bloat/complexity tarpit.
I'm not sure we'll know how bad it is without implementing a prototype.
Sigh.

Does anyone else have an opinion on whether it's worth it?

Havoc