[Telepathy] Account.Interface.ChannelRequests

mikhail.zabaluev at nokia.com mikhail.zabaluev at nokia.com
Mon Nov 24 06:14:31 PST 2008


>-----Original Message-----
>From: telepathy-bounces at lists.freedesktop.org 
>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
>ext Will Thompson
>Sent: Monday, November 24, 2008 3:08 PM
>To: telepathy at lists.freedesktop.org
>Subject: Re: [Telepathy] Account.Interface.ChannelRequests
>Dafydd Harries wrote:
>> Ar 24/11/2008 am 13:04, ysgrifennodd Alberto Mardegan:
>>> - Performance: The ChannelDispatcher object is not 
>necessary, and the 
>>> ChannelRequest is a good thing only in theory: with its 
>Proceed() method and the 
>>> need to connect to the Failed and Succeeded signals, I'm 
>afraid it's making 
>>> things slower.

Connecting to GObject signals hardly has any impact.
Installation of watches for DBus signals is done internally by DBus-Glib. If it's done suboptimally, it's a common problem and needs to be fixed as such, but we shouldn't design our APIs to work around it.

>> Signals don't need to be connected each time, you can just 
>add a message filter
>> that match on interface + signal name, which has a one-off 
>setup cost.
>No, you can't, because then you get woken up about *every* channel
>request, which is what the "Request as separate object" design 
>is trying
>to avoid.

True. And it might outweigh the need to call Proceed. A needless wakeup of a "cold" process which happens to listen to the same object's signals may be very costly.
We already talked about how the client library can completely hide Proceed.

Best regards,

More information about the Telepathy mailing list