In an attempt to address bug 45337, I tried to implement a gconf scheme in
GnomeVFSMIMEMonitor that would allow all instances of GnomeVFSMIMEMonitor (in
all processes) to emit their data_changed signal when any client in any process
called one of the gnome-vfs-mime-info API routines that changes the MIME
database. However, this gconf scheme failed, and I had to back it out. The
symptom of the failure was that a call to gconf_client_set_int in the MIME
monitor code would not update the value, and an ORBit error would show up that
looked like this:

ORBit-WARNING **: Request notify, ID -1073746560 was rejected by the
authentication mechanism!

The same code in GnomeVFSMIMEMonitor worked properly when called directly from
Nautilus (in an experiment), so it seems that either (1) some sort of necessary
initialization is done in the Nautilus case but not the capplet case, or (2) the
capplet or the control panel in general uses some mechanism that prevents
gconf/ORBit from working properly. (1) seems less likely, because I verified
that gconf_init is being called before any other attempt to use gconf.

I've got changes in local files that demonstrate this problem, but I'm not going
to check them in, and eventually they will go stale.



------- Additional Comments From sullivan@eazel.com 2001-01-05 11:11:33 ----

Note that this blocks bug 45459 (icon changes in capplet aren't reflected
immediately in Nautilus), though it is conceivable that 5459 could be fixed a
different way some day, such as via file node monitoring.



------- Additional Comments From sullivan@eazel.com 2001-01-05 11:16:01 ----

Here's some possible clues from an email exchange involving Havoc 
Pennington and Elliott Lee:

> "John Sullivan" <sullivan@eazel.com> writes:
> > I've got code to call gconf_init if it isn't already initialized before I
> > make any other gconf calls. I verified (just now) that it is in fact already
> > initialized when this code is reached.
>
> Oh - hang on. I remember the problem. GConf doesn't like libgnorba.
> Doh doh doh. I already knew about this issue. ;-)
>
> Or more specifically, IIRC OAF doesn't like libgnorba.  Both OAF and
> gnorba are setting up the magic authentication cookie for ORBit. I can
> remember having a detailed understanding of this issue and an opinion
> on it, but I can't remember what my understanding was anymore. Maciej
> and Elliot will have a better memory most likely.

OAF shouldn't be setting the cookie and shouldn't care about whether it is
set, unless Maciej added some mega-funkiness in.

-- Elliot



------- Additional Comments From darin@bentspoon.com 2001-01-05 12:18:49 ----

I think in the end this will be fixed by GNOME 2.0 where the control center
would use oaf, not gnorba (and somehow adapts old capplets) -- there might not
be a good way to fix it before then. But maybe I'm confusing the control center
with the panel.



------- Additional Comments From jirka@5z.com 2001-01-05 12:25:13 ----

it is possible to use gnorba and oaf int he same process by the use of a
somewhat ugly hack.  The thing is that gnorba wants to use cookies and oaf
doesn't set them up.  One way to solve this is to disable cookie checking (but
not setting).  grapevine does this and it appears to work nicely.  See
grapevine/src/main.c and search for "UTTER HACK"



------- Additional Comments From brett@eazel.com 2001-03-12 19:47:24 ----

(sorry for the spam, making self qa contact)



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:53 -------
Bug blocks bug(s) 45459.