On 27/09/13 22:41, Tiago Katcipis wrote: > On Fri, Sep 27, 2013 at 12:28 PM, Simon McVittie > <simon.mcvit...@collabora.co.uk <mailto:simon.mcvit...@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 _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy