Calling back to a calling process after dbus_g_proxy_call_no_reply

[Braden McDaniel]

On Fri, 2008-08-15 at 22:47 -0400, Havoc Pennington wrote:
> 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.

The latter case is in the ballpark of what I'm doing; so I might
investigate this further in the future. For now, I'm content to go
through the bus daemon. The data I'm transmitting will regularly be
large; though hopefully it will be "very large" only occasionally.

I'm sure there are several better-performing options. But a reasonably
full-featured RPC system is quite useful for what I'm doing; and D-Bus
saves me from inventing my own.

Thanks for the explanation.

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