After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 88829 - notifications between distinct GConfDatabases and arbitrary composite GConfDatabases
notifications between distinct GConfDatabases and arbitrary composite GConfDa...
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gconf
CVS HEAD
Other All
: High normal
: GNOME2.6
Assigned To: GConf Maintainers
Luis Villa
Depends on:
Blocks:
 
 
Reported: 2002-07-23 03:13 UTC by Mark McLoughlin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (31.77 KB, patch)
2002-07-23 03:32 UTC, Mark McLoughlin
none Details | Review
Might as well include some notes to myself while doing the first part so you can check over my logic (1.56 KB, text/plain)
2002-07-23 03:36 UTC, Mark McLoughlin
  Details

Description Mark McLoughlin 2002-07-23 03:13:48 UTC
I was going to split this patch into two seperate bugs, but the two of them
are fairly interdependant.

The first part allows notifications to take place between different
GConfDatabases. e.g. if you're directly modifying the defaults database,
applications who's view of the the default composite db has changed will
get notified.

The second part adds API to allow applications (e.g. gconf-editor or
gconftool) to work on arbitrary composite databases. This way you can model
how it would look if you added another configuration source to the default
database.

Issues with the patch (marked by FIXME):

* I arbitrarily picked ';' as the delimeter for a stringified list of
database addresses, this may not be the best choice

* I did not call gconfd_notify_other_listeners from
gconf_database_notify_listeners because I either would have had to modify
the gconf_database_notify_listeners signature (adding a 'notify_others'
flag for example) or use static variables to flag when not to recurse - but
the former would be an API/ABI change and the later could possibly lead to
re-entrancy hell.

* I implemented gconf_sources_first_writable instead of the possibly better
solution of returning the GConfSource affected in gconf_source_set_value.
Again, I didn't want to modify the API.

* In gconfd_notify_other_listeners, I just passed through is_default and
is_writable. They may have to be re-computed - I'm not sure, and it was
pure laziness that stopped me from checking it out further.
Comment 1 Mark McLoughlin 2002-07-23 03:32:27 UTC
Created attachment 10012 [details] [review]
patch
Comment 2 Mark McLoughlin 2002-07-23 03:36:44 UTC
Created attachment 10013 [details]
Might as well include some notes to myself while doing the first part so you can check over my logic
Comment 3 Luis Villa 2002-07-25 19:35:13 UTC
I'm not at all qualified to assess the importance of the problem;
don't take the lack of actual triage to mean 'this is only a normal
problem.'
Comment 4 Havoc Pennington 2003-07-02 23:53:43 UTC
huge patch!

A quick comment based on skimming, I believe gconf_sources_* and
gconf_database_* are entirely private, not-installed APIs that can be
changed - so some of your FIXME may be possible to fix.
Comment 5 Havoc Pennington 2003-10-22 20:25:12 UTC
This is going to massively conflict/overlap with Cyrille's patch isn't it?

Hmm, fun.

We need to get "make check"/"make check-coverage" going as with dbus,
that would be *so* helpful with all this refactoring...
Comment 6 Mark McLoughlin 2004-03-29 17:13:52 UTC
Posted a re-worked version of the patch to:

http://mail.gnome.org/archives/gconf-list/2004-March/msg00017.html
Comment 7 Mark McLoughlin 2004-04-19 07:50:15 UTC
Hmm, I've committed this now