[Telepathy] How to handle a lost closed signal

[Simon McVittie]

On 27/09/13 15:40, Tiago Katcipis wrote:
> Thanks for your reply (incredibly complete :-)

We've given this sort of thing a lot of thought over the last few years :-)

> This already gives an idea of a way to check if a proxy to an object is
> valid. Checking telepathy glib i could see that it TpProxy already has
> this concept:
> 
> http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-proxy.html#tp-proxy-get-invalidated

That's actually a slightly stronger concept: it's used to track objects
that have vanished from D-Bus altogether. A (client proxy for a) Call1
channel doesn't emit invalidated when it terminates; it only emits
invaliated on Closed (or a CM crash or whatever).

TpProxy also has tp_proxy_prepare_async() which encapsulates the concept
of "this thing is ready, and we've verified that it actually exists"
(and also checking for and configuring optional features/interfaces).

> It seems to be a good idea to implement a generic wrapper around DBus
> proxies to implement this kind of checking (avoiding the replication of
> the checking on all clients).

Checking whether a D-Bus object is valid is domain-specific: there is no
API that every D-Bus object is guaranteed to implement. In any case, to
minimize bus traffic, you usually want to do the validity check as a
side-effect of something domain-specific and useful that you wanted to
do anyway (e.g. GetAll), rather than a separate method call.

For GDBusProxy subclasses, implementing g_async_initable_async() is a
good way to encapsulate the initial "is it intact?" check and state
download. If we were writing telepathy-glib now, the "core" feature on
each proxy would probably be represented by g_async_initable_async().

> I can see [round-trip avoidance] on the Connection.Requests interface:
> 
> http://telepathy.freedesktop.org/spec/Connection_Interface_Requests.html#Struct:Channel_Details
> 
> It can even prevent some observers from creating proxies if they only
> need the immutable information, nice.

Like I said, we've put a lot of thought into this sort of thing. We're
currently deleting all the "first attempt" APIs from the Telepathy 1.0
branch, so it will only have the revised, good ones :-)

>     * change notification: if there's a GetThings method or a readable
>       property, then there should be a way to keep up with its current
>       value by watching signals, to avoid having to poll
> 
> Here we are doing something a little different, since properties on
> GDBus can be monitored we where just using readable properties and if
> they change GDBus will deliver the change on the "notify:property-name"
> signal (PropertiesChanged signal under the hood to do this).

PropertiesChanged *is* a change-notification implementation - it's just
a way to share the change notification infrastructure between 99% of
interfaces (so GDBus has more code, and you have less).

Similarly, Properties.GetAll() and the ObjectManager interface provide a
"95%" implementation of state recovery and change notification, so that
in common cases (object trees with a small-to-medium branching factor)
you don't have to invent quite so many wheels.

Some parts of Telepathy use PropertiesChanged, some parts only don't use
it because they were written first, and some (the Group interface, as
used on IRC) are in the 1% where PropertiesChanged is likely to be a
performance problem.

    S