[Telepathy] How to handle a lost closed signal

[Simon McVittie]

On 27/09/13 22:41, Tiago Katcipis wrote:
> On Fri, Sep 27, 2013 at 12:28 PM, Simon McVittie
> <simon.mcvittie at collabora.co.uk <mailto:simon.mcvittie at collabora.co.uk>>
> wrote:
> 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 don't know whether the recommendation from the authors of GDBus is for
domain-specific proxies (the equivalent of TpChannel etc.) to be
subclasses a of GDBusProxy for the "main interface" (an "is-a"
relationship - "MyProxy is a GDBusProxy", or unrelated objects that have
one or more GDBusProxy instances as members (a "has-a" relationship:
"MyProxy has a GDBusProxy").

I believe the GDBus code-generation tools generate an unrelated object
implementing GDBusObject, which has GDBusProxy instances as members.

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

The potential performance problems with PropertiesChanged are if the
changes are small compared with the new value: either you put the new
value in the signal and it's huge, or you put it in the "invalidated"
set, every interested client downloads the new value via Get() or
GetAll(), and it's still huge. If you're implementing one of the few
D-Bus services where this is a problem, you can solve this by having a
domain-specific signal that contains some sort of diff between the old
and new values.

The classic example in Telepathy is the property "list of members" on a
TpChannel representing a large IRC channel like #ubuntu. If I join, it's
better to emit a small signal that means "smcv joined", rather than a
large signal that means "the members changed to aardvark, aaron, ...,
smcv, ...".

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

Yes. Between 1 and 2, any amount of time can pass, and the Handler can
still call methods on the channel (although many of them will fail);
then 2 triggers 3 "immediately".

The ChannelDispatcher API says Channels don't have a Handler until all
Observers (loggers, etc.) have all said "I'm ready" (by returning a
value from their ObserveChannels method), which means that an Observer
can expect that until it has said "I'm ready", step 2 won't happen. So,
Observers can call methods on the channel too, to find all the
information they need to log.

    S