On Fri, Sep 27, 2013 at 12:28 PM, Simon McVittie <simon.mcvittie@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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy >
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
