[Telepathy] How to handle a lost closed signal

[Tiago Katcipis]

On Fri, Sep 27, 2013 at 12:28 PM, Simon McVittie <simon.mcvittie at collabora
.co.uk> wrote:

> 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().
>

By this you mean inherit from the GDBusProxy and extend the initialization
process right? because from my experience GDBus does no validation on the
proxies you create, you can create a proxy to any crap and it will be well
succeeded :-) (it will deliver to you an awesome GDBusProxy pointer).



>
> > 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.
>

I see, good to know that there is no problem on using properties changed
(performance can be a problem, so I'm going to keep my eyes open :-).

When you said that the Call1 already has support for termination but still
existing on DBus you mean that:

1 - Call1 will  emit a CallStateChanged to Ended.
2 - Someone call the Channel interface Close method (the handler?).
3 - Then the Closed signal is emitted and the object is no longer valid.

This idea really seems to be a start to solve our problems, not all, but
some.

Regards,
Tiago Katcipis


>
>     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/c4b938e0/attachment.html>