[11:26:27]  ***  owen (~otaylor@lan-nat-pool-bos.redhat.com) has joined chat #fedora-desktop. [11:26:29]  ***  owen has been oped by _halfbot. [11:29:51]  owen: interestingly it looks like gconfd already allows different clients to access different config sources [11:30:24]  owen: so you could in theory use the already running gconfd instead of keeping it local [11:30:29]  to libgconf [11:30:35]  ***  rtcm (~jman@109.81.54.77.rev.vodafone.pt) has joined chat #fedora-desktop. [11:31:12]  halfline: code reference? [11:32:50]  so gconf_engine_get_for_addresses ends up doing ConfigServer2_get_database_for_addresses [11:33:09]  which goes to gconfd_get_database_for_addresses [11:33:20]  then the engine does all it's queries against the returned database [11:33:33]  normally you don't use gconf engine apies [11:33:37]  but instead use gconf client [11:33:43]  which uses gconf_engine_get_default [11:33:46]  under the hood [11:34:19]  the defaults mechanism in gconf uses that, iirc [11:35:40]  so the patch would just check the environment variable and call gconf_engine_get_for_addresses instead of gconf_engine_get_default [11:36:10]  halfline: well, it would have to parse the path file for the system daemon to find out the system configured addresses first [11:36:22]  right, which is normally done daemon side [11:36:28]  but gconftool does it too i think [11:36:31]  lemme look [11:36:50]  gconttool does it I think if there is no session [11:37:06]  right [11:37:13]  so we just would add similar code to libgconf [11:37:39]  do things work out properly for notification, etc, if there are multiple databases within the gconfd process? [11:37:53]  that i don't know [11:38:12]  i do know notifications don't work properly for process local config sources [11:38:49]  yeah, I don't care about that, but if mutter vs. gnome-wm-properties don't inter-notify properly, that's a problem [11:38:55]  sure [11:39:38]  ***  panchiz has left chat #fedora-desktop (Ping timeout: 600 seconds). [11:40:38]  ***  tbzatek has left chat #fedora-desktop (Leaving). [11:40:48]  so my thoughts are 1) it doesn't seem like it shouldn't work. having distinct databases seems to be an intrinsic part of gconfd design 2) i don't think gconf has really gotten much testing outside of gconf_engine_get_default() so things might be busted [11:41:03]  and i guess maybe 3) we should just try it since it can't be a big patch [11:41:48]  I don't see how it would work [11:42:22]  details please [11:42:29]  there doesn't seem to be any sharing of sources between different databases in gconfd [11:43:00]  okay so you're sayng if one database write happens [11:43:02]  So, if you have two databases with xml:readwrite:$(HOME)/.gconf , they'll just be separate [11:43:05]  the others aren't going to find out about it [11:43:08]  sources [11:43:13]  and if one changes, it won't notify the other [11:43:21]  hmm, no davidz [11:43:22]  (and there will be no shared caching either) [11:44:22]  i wonder what gconfd_notify_other_listeners is about [11:44:37]  * halfline reads it [11:45:45]  looks like a potential candidate. it's iterating over a global list of databases [11:45:50]  and finding matching sources [11:45:58]  let me see what calls it [11:46:02]  Yeah. I don't know why markmc didn't just share sources though [11:46:30]         (gconfd_notify_other_listeners): impl notifying listeners [11:46:30]          on GConfDatabases other than the one which was changed. [11:46:48]  was probably less code churn this way [11:46:50]  Is the commit message (part of the massive 3d720f4a0c00af31c commit that added gconf_engine_get_for_addresses()) [11:48:30]  so in theory this could work [11:48:37]  might have bugs though [11:48:42]  ***  mcepl has left chat #fedora-desktop. [11:48:44]  time for lunch