Calling back to a calling process after dbus_g_proxy_call_no_reply

Braden McDaniel braden at endoframe.com
Fri Aug 15 01:47:01 PDT 2008


On Thu, 2008-08-14 at 14:25 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Thu, Aug 14, 2008 at 1:49 PM, Braden McDaniel <braden at endoframe.com> wrote:
> >
> > It occurs to me that I have a rather poor handle on when to use
> > _new_for_name vs. _new_for_name_owner vs. _new_for_peer. I've read the
> > documentation for these as well as what I could find at freedesktop.org;
> > but I still don't feel like I have a handle on when each of these is
> > appropriate. In particular, with respect to _new_for_peer, I'm not clear
> > on what kind of set-up I need to be able to use this.
> >

[snip]

> If the owner of "org.openvrml.VrmlControlFactory" changes, do you want
> all method calls to just start going to the new owner, or do you want
> to start getting errors on the old proxy and have to create a new
> proxy, that's the bottom line question. If your method calls establish
> any state (if the order you call them in matters, for example) then
> you probably have to explicitly handle the owner change.

Thanks; that was very helpful. In my situation, the name owner is a
service; so, it shouldn't change. In that case it seems I should be
using _new_for_name_owner.

But, (not really unexpectedly) changing to _new_for_name_owner doesn't
change the problem I'm having at all. :-/

...

Argh. Going back to this, I think I see the problem:

        dbus_g_proxy_new_for_name(
            VRML_CONTROL_FACTORY_GET_CLASS(control_factory)->connection,
                "org.openvrml.VrmlControlFactory",
                host_obj_path,
                "org.openvrml.VrmlControlHost");

The name "org.openvrml.VrmlControlFactory" is owned by the *hosted*
process; the interface "org.openvrml.VrmlControlHost" is supported by
the *host* process.

After requesting a name for the host process and using that instead,
things seem to be working.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




More information about the dbus mailing list