[Telepathy] How to handle a lost closed signal

Fri Sep 27 07:40:08 PDT 2013

Simon,

Thanks for your reply (incredibly complete :-)

On Fri, Sep 27, 2013 at 10:01 AM, Simon McVittie <simon.mcvittie at collabora
.co.uk> wrote:

> On 27/09/13 13:12, Tiago Katcipis wrote:
> > I'm reading the telepathy specification and i have a doubt that i was
> > unable to find a answer until now, when a channel is created you start
> > to create a proxy to the new channel, but then the closed
> > (http://telepathy.freedesktop.org/spec/Channel.html#Signal:Closed)
> > signal is emitted, but before you can catch it since you are still on
> > the process of creating a proxy to it, how you handle this kind of race
> > condition on DBus objects?
>
> Just detecting it isn't such a problem: when setting up the proxy, you
> call a D-Bus method that all objects of that interface must implement
> (Properties.GetAll for the relevant interface, usually) and that do not
> fail under any normal circumstances (again, GetAll is ideal). If that
> fails, you know the object already went away :-)
>

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

http://telepathy.freedesktop
.org/doc/telepathy-glib/telepathy-glib-proxy.html#TpProxy-invalidated

It seems to be a good idea to implement a generic wrapper around
DBusproxies to implement this kind of checking (avoiding the
replication of the
checking on all clients). Sadly GDBus does not seem to have anything like
that on GDBusProxy (https://developer.gnome.org/gio/2.38/GDBusProxy.html).

Perhaps they would be prone to accept the implementation of the "valid
DBusobject" concept.

>
> The next problem is that because it has already gone away, maybe you've
> already lost some of the information you need. That's harder, but we've
> developed several ways to solve it.
>
> When we announce a new channel, we announce its "immutable properties"
> immediately:
>
>   - target handle (= contact or room you're talking to)
>   - type of channel
>   - initiator
>   - etc.
>
> which is enough to log a missed call, even if you never saw the actual
> D-Bus object in an "alive" state.
>

I can see this 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.

>
> Another technique is to have the object persist in a "dead" state until
> a client acknowledges it. Call1 channels (our modern API for VoIP calls)
> don't close until a client calls the Close() D-Bus method, even if the
> call has actually already terminated. With hindsight, all Telepathy
> channels (e.g. Text and tubes) should have always worked like this -
> it's too late to do that in Telepathy 0.x, but I'm considering it for
> Telepathy 1.0.
>

This one is interesting too, it seems to me that the observer/handler
pattern fits quite well here since it makes sense that only the handler can
call the Close method (since a observer transmits the idea to be passive
and not cause any side effect on the system).

>
> If you need multiple cooperating clients (which many APIs don't, but
> it's a lot of the point of Telepathy) then another technique is to have
> a policy by which multiple cooperating clients can agree when it's OK to
> close/delete the object. For instance, Telepathy clients use the
> ChannelDispatcher (Mission Control) as a coordination point, and agree
> that it is incorrect to close a channel until Mission Control has given
> it to a (single!) suitable Handler. Clients that implement Observer,
> like telepathy-logger, can delay that point while they do whatever
> sync-up they need to, because Mission Control will wait for them before
> it proceeds.
>
> > One way is to have a well know bus-name and object-path that notifies
> > about the channel being closed, but then it seems to be useless to have
> > the signal on the created object since you are obligated to monitor the
> > signal on the well know object to avoid losing the signal of the
> > recently created object.
>
> We do this too (e.g. Channel.Closed duplicates Connection.ChannelClosed,
> Account.Removed duplicates AccountManager.AccountRemoved). It isn't the
> most elegant thing in the world, but it's necessary if you want state
> recovery and change notification, which are two of our design principles:
>

We do something very similar here too, it started to sound odd, its good to
know that I'm not the only one that finds it not very elegant :-).

>
> * state recovery: if you miss signals, you can catch up on the current
>   state by calling a method or getting a property, although you might
>   miss old state transitions (e.g. you can get the list of channels,
>   even if you missed NewChannels and ChannelClosed signals)
>

We have this.

>
> * 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
GDBuscan 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).

Thanks again for sharing the knowledge.

Regards,
Tiago Katcipis

>
> Regards,
>     S
>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20130927/bfb444bd/attachment.html>