[Telepathy] The "new" avatars API

[mikhail.zabaluev at nokia.com]

My two cents below...

>-----Original Message-----
>From: telepathy-bounces at lists.freedesktop.org 
>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
>ext Alberto Mardegan
>Sent: Thursday, August 30, 2007 3:17 PM
>To: telepathy at lists.freedesktop.org
>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.