Re: EggDBus

[Murray Cumming <murrayc murrayc com>]

On Mon, 2008-12-22 at 11:01 -0500, David Zeuthen wrote:

> you'll have to use the supplied QUERY_INTERFACE macro for each of the
> generated interfaces to get an interface proxy. For example
> 
>  DevkitDevice *device;
> 
>  device = DEVKIT_QUERY_INTERFACE_DEVICE (object_proxy);
[snip]

Ah, so you hard-code the expected interfaces at build time. And
DEVKIT_QUERY_INTERFACE_DEVICE() won't check that the interface is really
provided by that object, though you could get an error when then trying
to call a function of that interface. 

That's unfortunately not very helpful for Telepathy, for which various
"connection managers" (providers of IM functionality for particular IM
protocols) may or may not implement various additional interfaces, so
you have to check if those interfaces are available and fall back to
alternatives when possible.

Not that I think that's a good situation (I like non-dynamic static
typing), but I guess there's no established way of doing
parallel-installs of D-Bus APIs, so they tend to evolve by adding
interfaces to stable versions, with some lag before those interfaces are
actually provided by everything that should implement them.

Anyway, this is not very relevant to you.

> Interface proxies are created on demand; e.g. only when used. There's no
> automatic discovery happening.. there is however an easy to use
> introspection facility
> 
> http://people.freedesktop.org/~david/eggdbus-0.1-docs/EggDBusObjectProxy.html#egg-dbus-object-proxy-introspect
> 
> that you can use to discover the available interfaces of a remote
> object.
[snip]

>From that documentation I couldn't tell where to actually get the
introspected information once that call has finished.

[snip]
> > Isn't D-Bus property getting and setting asynchronous? How can this
> work
> > with the non-async g_object_get() function?
> 
> Right now the first property_get() call on an interface proxy will
> synchronously invoke (blocking in libdbus on the dbus fd, not blocking
> in the main loop because that would cause reentrancy issues) the
> GetAll() method on the org.fd.DBus.Properties interface.
[snip]

As you say, this does mean that it's particularly important for property
getting to be fast in the D-Bus service, meaning, for instance, that a
Telepathy object shouldn't get the information from a remote server.

[snip]
> Setting a property currently involves doing a sync call from
> property_set() that blocks until the server acknowledges the write with
> a reply.

The Telepathy coders seem to have a strong dislike for blocking sync
D-Bus calls even when the call can be expected to complete quickly,
though I think that's partly due to problems with their version of sync
calls, and how they use the mainloop, as well as some D-Bus bugs:
http://lists.freedesktop.org/archives/telepathy/2008-November/002520.html
and
http://lists.freedesktop.org/archives/telepathy/2008-November/002521.html
 
Again, that's not particularly relevant to you. I'm just mentioning it
because I have my head in all this stuff at the moment.

>  I have a TODO item to make this async but it's hard (though not
> impossible) to implement correctly because of coherency issues. Note
> that there's very few services in the wild with writable properties.
> 
> For changes, there's unfortunately no Changed() signal on the official
> org.fd.DBus.Properties interface. For now I'm using a signal called
> EggDBusChanged()) on said interface (embrace and extend!); FWIW, I'm
> going to propose the Changed() signal on the D-Bus list.
[snip]

> [1] : I'd argue that if property get/set can fail, then the provider of
> the D-Bus service is doing something wrong and it shouldn't be a
> property in the first place. But, hey, things like this can happen.
[snip]

I agree that D-Bus APIs should document restrictions on the behaviour of
implementations, such as whether they can fail and how long they may
take, allowing application code to be simpler by avoiding async calls.
That's something else that Telepathy doesn't seem happy to do.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com