"atomic" notifications

[Havoc Pennington <hp redhat com>]

Hi,

Another TODO list item!

GConf currently has GConfChangeSet that is supposed to represent a set
of atomic changes to make. I don't intend to actually implement
transaction semantics in gconfd in the near future, but we can make
things somewhat better.

A common case is that two settings are interrelated and must be
changed simultaneously; I'm not thinking of an example right this
minute, but people have requested the feature.

Right now if you commit a change set containing these two settings,
the client will be notified of the two changes separately, resulting
in a momentary inconsistent state for the client.

I don't want to fool with any complicated solution, but want to
support the following:

  void 
  notify_calllback_attached_to_setting_A ()
  {
    /* This should return the new value of B, not the old
     * one.
     */
    value = gconf_get ("/setting_B");

  }

That is, once you get a notification for any member of a ChangeSet,
then getting the value of another member will get the new value from
the ChangeSet.

This just means setting all the values in a changeset, and only then
doing notifications for them. Also, it means we need to invalidate the
cache inside GConfClient for all values in the set before doing
notifications for any of the values (should mean simply passing a list
of keys to invalidate to the client). This is because the GConfClient
cache is kept up-to-date via notifications.

Unfortunately clients still have to be robust against getting
inconsistent settings, because ChangeSet isn't really transactional,
because GConf notifications and values are basically untrusted data
off the network, and because a sysadmin could do something dumb like
install a mandatory value for one setting and not the other.
So on that level I'm not sure this change is super-useful.

Havoc