Calling back to a calling process after dbus_g_proxy_call_no_reply

[Havoc Pennington]

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.
>

* new_for_peer would be used if you are not using the bus daemon (if
you write your own thing that listens for connections using
DBusServer). Probably you aren't doing this.

* new_for_name is used if you want the proxy to mean "whichever
process currently owns the name". This means if you call method a()
then b(), those calls could go to two different processes because one
exited and the other took over.

* new_for_name_owner is used if you want the proxy to refer to "the
process that owns the name *now*". So if the owner of the well-known
name changed, your proxy would still refer to the old owner. This
implies that you need a new proxy for each new process.

The choice between new_for_name and new_for_name_owner depends on
which kind of complexity is easier to deal with in your case. If your
method calls are all standalone with no implied state, i.e. it does
not matter if call a() and call b() go to a different process,
new_for_name() is simpler. But if it would confuse your app to have
a() and b() go to two different processes, you would need to
explicitly deal with name ownership changes, and that means
new_for_name_owner() is more appropriate.

Also, new_for_name_owner() just means to bind to the "unique"
on-the-fly-generated name. If you already know this name, then calling
new_for_name() on the unique name, is the same as doing
new_for_name_owner() on the well-known name. new_for_name_owner() just
gets the unique name of the current owner, then binds to that.

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.

Note that it does NOT work to send method calls to the well-known name
("org.openvrml.VrmlControlFactory") but subscribe to owner-changed
events, because the owner can change after you send a method call, but
before you get the owner-changed event.

Havoc