My two cents below... >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >ext Alberto Mardegan >Sent: Thursday, August 30, 2007 3:17 PM >To: [email protected] >Subject: [Telepathy] The "new" avatars API > >In the latest version(s) of the Telepathy specifications, the >RequestAvatar API has been deprecated. > >I was in the process of changing MC to use the new >RequestAvatars() API, >and while testing it I noticed something that I don't like. Basically, >when an avatar changes I'm receiving three AvatarRetrieved signals; >after my initial surprise I realised that that's because MC is not the >only process interested in retrieving the avatars, so there are other >processes reacting to AvatarChanged and calling RequestAvatars(). > >I guess it's not that hard to find a solution, I can probably >just check >if the token is changed and ignore the signals if it's the same, but >this is not the problem. > >The problem is that IMHO the paradigma of: > >1) Process A requests information >2) Information is delivered to everybody through a signal > >sucks. We are transmitting data and waking up processes for no reason. >What was wrong with the old API? I'm totally fine with the new >RequestAvatars API, but why not return the avatars in the call >reply itself? >I could also be fine with the AvatarRetrieved signal, if it were >spontaneously emitted by the CM, but if it has to be >requested, how can >my process know whether another process already asked for it?
Maybe, the simplest fix is to aggregate outstanding avatar requests to prevent re-emission of the signal for one update of the avatar. _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
