Re: config system thoughts

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp@redhat.com> writes:

> On Wed, 21 Jul 1999, Elliot Lee wrote:

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

You have to decide what configuration keys are global to
all instances of an application, and what configuration
keys apply to a single instance of an application.
(This is the data that is session-managed with the
application.) In some cases, you may have overrides.

I think you would agree that if, say, the background
color, is a global, non-session-managed
setting, then the ideal behavior is to change it
for all gnome-terminals immediately.

It would be confusing behavior if it changed for
only one terminal, but when you logged out and logged
back in, it was changed for the rest. 

This example may not be completely practical to change
(what if you bring up the properties dialog in two
separate gnome-terminals simultaneously?), but I
think it should clear that the ideal behavior for
global properties is instant updates.

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

If you were using GtkObjects here, I'd suggest that you
would create a listener for some portion of the config
herirarchy. It could be all keys for the application,
a subset, or just one particular key.
  
> > > 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.

The communication here is almost all occuring only when
a key is written. And a configuration system has a
very high read/write ratio. There might have to 
be some thought given to the communication architecture
to get decent performance, but my gut feeling is
that it should be quite manageable. A few obvious
optimizations:

 - Notifications are one-way; you don't need context
   switches.

 - You can batch notifications. This could be done
   mutiple ways:

    a) You could batch based on locking or transactions.
       If a program has a section of the database locked,
       then you can make a single notification call
       for all changes in the section when the lock
       is released.

    b) You could batch as X does; notifications aren't
       flushed to the central daemon until something
       requires a response from the central daemon
       or until the modifying application goes into
       a select() wait.

I'd dispute the "dubious value" part of this. The value
is clear:

 - Avoids having to write a new CORBA API for changing every
   single config key.

 - Instant updates. This is a _big_ benefit, I would argue.
   Once you get used to it for something like themes, it
   seems really stupid to have to restart programs 

 - Makes caching possible; gnome-config currently is completely
   broken because it caches tons of data, but has no 
   mechanism to notice when things change underneat it.

Now, these benefits may not outweight the extra work
needed, but I see having a notification service for
configuration changes as something that could make 
GNOME a lot more elegant, powerful, and even robust.

Regards,
                                        Owen