<div dir="ltr">Simon,<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your reply (incredibly complete :-)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 10:01 AM, Simon <span style class="">McVittie</span> <span dir="ltr"><<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank"><span style class="">simon</span>.<span style class="">mcvittie</span>@<span style class="">collabora</span>.co.<span style class="">uk</span></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 27/09/13 13:12, Tiago Katcipis wrote:<br>
> I'm reading the telepathy specification and i have a doubt that i was<br>
> unable to find a answer until now, when a channel is created you start<br>
> to create a proxy to the new channel, but then the closed<br>
> (<a href="http://telepathy.freedesktop.org/spec/Channel.html#Signal:Closed" target="_blank">http://telepathy.freedesktop.org/spec/Channel.html#Signal:Closed</a>)<br>
> signal is emitted, but before you can catch it since you are still on<br>
> the process of creating a proxy to it, how you handle this kind of race<br>
> condition on DBus objects?<br>
<br>
</div>Just detecting it isn't such a problem: when setting up the proxy, you<br>
call a D-Bus method that all objects of that interface must implement<br>
(Properties.GetAll for the relevant interface, usually) and that do not<br>
fail under any normal circumstances (again, GetAll is ideal). If that<br>
fails, you know the object already went away :-)<br></blockquote><div><br></div><div>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 <span style class="">TpProxy</span> already has this concept:<br>
<br><a href="http://telepathy">http://telepathy</a>.<span style class="">freedesktop</span>.org/doc/telepathy-glib/telepathy-glib-proxy.html#<span style class="">tp</span>-proxy-get-invalidated<br><br></div><div><a href="http://telepathy">http://telepathy</a>.<span style class="">freedesktop</span>.org/doc/telepathy-glib/telepathy-glib-proxy.html#<span style class="">TpProxy</span>-invalidated<br>
<br></div><div>It seems to be a good idea to implement a generic wrapper around <span style class="">DBus</span> proxies to implement this kind of checking (avoiding the replication of the checking on all clients). Sadly <span style class="">GDBus</span> does not seem to have anything like that on <span style class="">GDBusProxy</span> (<a href="https://developer.gnome.org/">https://developer.gnome.org/</a><span style class="">gio</span>/2.38/<span style class="">GDBusProxy</span>.html).<br>
<br></div><div>Perhaps they would be prone to accept the implementation of the "valid <span style class="">DBus</span> object" concept.<br></div><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The next problem is that because it has already gone away, maybe you've<br>
already lost some of the information you need. That's harder, but we've<br>
developed several ways to solve it.<br>
<br>
When we announce a new channel, we announce its "immutable properties"<br>
immediately:<br>
<br>
- target handle (= contact or room you're talking to)<br>
- type of channel<br>
- initiator<br>
- etc.<br>
<br>
which is enough to log a missed call, even if you never saw the actual<br>
D-Bus object in an "alive" state.<br></blockquote><div><br></div><div>I can see this on the Connection.Requests interface:<br><br><a href="http://telepathy">http://telepathy</a>.<span style class="">freedesktop</span>.org/spec/Connection_Interface_Requests.html#<span style class="">Struct</span>:Channel_Details<br>
</div><div><br></div><div>It can even prevent some observers from creating proxies if they only need the immutable information, nice.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another technique is to have the object persist in a "dead" state until<br>
a client acknowledges it. Call1 channels (our modern API for VoIP calls)<br>
don't close until a client calls the Close() D-Bus method, even if the<br>
call has actually already terminated. With hindsight, all Telepathy<br>
channels (e.g. Text and tubes) should have always worked like this -<br>
it's too late to do that in Telepathy 0.x, but I'm considering it for<br>
Telepathy 1.0.<br></blockquote><div><br></div><div>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).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you need multiple cooperating clients (which many APIs don't, but<br>
it's a lot of the point of Telepathy) then another technique is to have<br>
a policy by which multiple cooperating clients can agree when it's OK to<br>
close/delete the object. For instance, Telepathy clients use the<br>
ChannelDispatcher (Mission Control) as a coordination point, and agree<br>
that it is incorrect to close a channel until Mission Control has given<br>
it to a (single!) suitable Handler. Clients that implement Observer,<br>
like telepathy-logger, can delay that point while they do whatever<br>
sync-up they need to, because Mission Control will wait for them before<br>
it proceeds.<br>
<div class="im"><br>
> One way is to have a well know bus-name and object-path that notifies<br>
> about the channel being closed, but then it seems to be useless to have<br>
> the signal on the created object since you are obligated to monitor the<br>
> signal on the well know object to avoid losing the signal of the<br>
> recently created object.<br>
<br>
</div>We do this too (e.g. Channel.Closed duplicates Connection.ChannelClosed,<br>
Account.Removed duplicates AccountManager.AccountRemoved). It isn't the<br>
most elegant thing in the world, but it's necessary if you want state<br>
recovery and change notification, which are two of our design principles:<br></blockquote><div><br></div><div>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 :-).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* state recovery: if you miss signals, you can catch up on the current<br>
state by calling a method or getting a property, although you might<br>
miss old state transitions (e.g. you can get the list of channels,<br>
even if you missed NewChannels and ChannelClosed signals)<br></blockquote><div><br></div><div>We have this.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* change notification: if there's a GetThings method or a readable<br>
property, then there should be a way to keep up with its current<br>
value by watching signals, to avoid having to poll<br></blockquote><div><br></div><div>Here we are doing something a little different, since properties on <span style class="">GDBus</span> can be monitored we where just using readable properties and if they change <span style class="">GDBus</span> will deliver the change on the "notify:property-name" signal (<span style class="">PropertiesChanged</span> signal under the hood to do this).<br>
<br></div><div>Thanks again for sharing the knowledge.<br><br></div><div>Regards,<br></div><div><span style class="">Tiago</span> <span style class="">Katcipis</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
S<br>
<br>
_______________________________________________<br>
telepathy mailing list<br>
<a href="mailto:telepathy@lists.freedesktop.org">telepathy@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/telepathy" target="_blank">http://lists.freedesktop.org/mailman/listinfo/telepathy</a><br>
</blockquote></div><br></div></div></div>