Calling back to a calling process after dbus_g_proxy_call_no_reply
Havoc Pennington
hp at pobox.com
Fri Aug 15 19:47:50 PDT 2008
Hi,
On Fri, Aug 15, 2008 at 10:29 PM, Braden McDaniel <braden at endoframe.com> wrote:
>> * 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.
>
> Under what sort of circumstances would I *want* to do this?
>
The bus daemon gives the desktop session a "star" or "hub and spoke"
configuration and allows apps to keep track of each other with the
concept of owning bus names (global names on the daemon that can be
owned by only one app at a time). The bus daemon also does things like
route signals to multiple apps. The "hub and spoke" setup allows
everyone to talk to everyone else without having a huge number of
sockets open in a haphazard graph.
In some cases you really want to connect directly to another app,
though, instead of connecting to the "hub." One example is if you want
to use dbus in a way similar to http, with a server on one machine and
connecting anonymously over tcp from another machine. Another example
is within a desktop session, if you were going to transmit a very
large chunk of data, you might want to set up a direct connection on
the side to avoid copying it through the bus daemon. "Very large"
probably means many megabytes, and there are probably better choices
than dbus for the direct connection anyway.
If you are writing a desktop app there is rarely any reason to use
DBusServer directly. The primary reason it exists is that dbus-daemon
itself is implemented using libdbus public API, it is not "special" in
any way with respect to libdbus. So the public API has to have the
stuff dbus-daemon needs.
This is done as a matter of clean layering; first there's an IPC
protocol that just allows two processes to talk to each other, and
then built on that is a special process dbus-daemon that facilitates
routing messages in a hub-and-spoke way.
In libdbus, only dbus-bus.h is in any way specific to the bus daemon,
everything else makes equal sense without the daemon.
Havoc
More information about the dbus
mailing list