[Telepathy] [Bug 18176] Don't get a signal after "RequestAvatars"

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=18176


Will Thompson <will.thompson at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |NOTABUG




--- Comment #2 from Will Thompson <will.thompson at collabora.co.uk>  2008-10-24 03:07:34 PST ---
To check if an avatar is available, you call GetKnownAvatarTokens to get a map
from contact handles to avatar tokens, which are the empty string if that
contact is known not to have an avatar. Having done that, you can kick off
RequestAvatars for contacts whose avatar token in that map is not the empty
string.

Also, bind to the AvatarUpdated signal to be informed when the situation
changes for any given contact.

So to figure out whether the self-handle has an avatar, call
GetKnownAvatarTokens([self]) and look up self in the returned map.

* If it maps to a non-empty string, there's an avatar set, and the client can
download it with RequestAvatars([self]), safe in the knowledge that it'll
either get an AvatarRetrieved signal when it's been downloaded, or (in an
unlikely situation where the user is changing their avatar on some other
connection) it'll get AvatarUpdated for the self handle, at which point it
should reconsider based on the new token in that signal.

* If it maps to the empty string, there's no avatar set, and calling
RequestAvatars([self])  If you're on a rubbish protocol where avatars don't
persist across connections, self will not be included in the returned map; at
that point, a client should probably re-set its own idea of what the user's
avatar is.

(Some CMs (Butterfly, IIRC) don't support GetKnownAvatarTokens, but support
only GetAvatarTokens, which causes network roundtrips to retrieve the tokens
for the specified contacts before returning. You could consider this to be a
bug in those CMs, and ignore them. :-))


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.