dbus_g_proxy_new_for_name()

[Havoc Pennington]

Hi,

On Tue, Dec 9, 2008 at 10:56 AM, Murray Cumming <murrayc at murrayc.com> wrote:
> While thinking about some fundamental D-Bus API stuff,
> I have a couple of questions about dbus_g_proxy_new_for_name()
> http://dbus.freedesktop.org/doc/dbus-glib/dbus-glib-DBusGProxy.html#dbus-g-proxy-new-for-name
>
> Does it actually check that the object (identified by the name and path)
> actually implements the requested interface? If so, shouldn't that
> function have a GError* parameter to tell me if the interface is not
> implemented, or even to tell me that the name and path don't provide an
> object?

It doesn't check any of this; new_for_name() is supposed to be a
"loosely coupled" thing where it doesn't even see if the name exists,
the proxy is just always there, and if the name isn't there or is
owned by a wrong remote process, then you'll just get errors when you
try to call methods.

This means new_for_name() doesn't have to do any blocking calls when
the proxy is created, and it means you don't have to recreate the
proxy if the remote service restarts or is replaced.

> Shouldn't there be an async version of dbus_g_proxy_new_for_name() given
> that it requires use of the network?

It should not use the network in a blocking way, that's part of the
point of it as opposed to new_for_name_owner(). It should install
signal match rules but that shouldn't need to block.

Caveat: I haven't read any of this code lately, just talking about the
intent when I introduced this API years ago.

I don't think any of this is really how you want to do things if you
were designing an API from scratch today, I've been doing things quite
differently in hacked-together dbus wrappers like
hippo-dbus-helper.[hc] for example.

Havoc