[Telepathy] [Bug 12465] Current avatars API is likely to generate too much DBus traffic

[bugzilla-daemon at freedesktop.org]

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





--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2008-01-22 06:31:37 PST ---
(In reply to comment #13)
> The more I think of it, the less I can find a reason not to have the avatar
> data in the AvatarUpdated signal

Ah, I see. The crucial fact you're missing is the reason the Avatars interface
was ever this complicated: many network protocols tell us the avatar has
changed, with some sort of summary, checksum or timestamp (in Telepathy we
encapsulate all these as a "token"), *without* actually sending us the whole
avatar.

The whole design of the Avatars interface is based on trying to minimize the
number of times we download the entire avatar from the server.

If the clients had a correct avatar cache ("correct" in the sense that it does
what we propose it should do), we'd get something like this the first time:

XMPP server: <presence from="bob at example.com"><avatar-sha1
sha1="deadbeefdeadbeefdeadbeef">
Gabble: AvatarUpdated(bob_handle, "deadbeefdeadbeefdeadbeef")
Client: *looks in cache for
"gabble/jabber/bob at example.com/deadbeefdeadbeefdeadbeef", can't find it*
Client: RequestAvatars([bob_handle])
Gabble: <iq type="get"><vCard/></iq>
Server eventually replies: <iq type="result"><vCard>[insert 11K of Base64
here]</vCard></iq>
Gabble: AvatarRetrieved(bob_handle, [insert 8K of JPEG here], 'image/jpeg')
Client: *puts in cache and displays to user*

but in a later session, after you've disconnected and reconnected:

XMPP server: <presence from="bob at example.com"><avatar-sha1
sha1="deadbeefdeadbeefdeadbeef">
Gabble: AvatarUpdated(bob_handle, "deadbeefdeadbeefdeadbeef")
Client: *looks in cache for
"gabble/jabber/bob at example.com/deadbeefdeadbeefdeadbeef"*
Client: *displays to user*

This does save sending 8K of binary over D-Bus (not that we really care), but
that's not the goal - the goal is that it saves downloading 11K of Base64 from
the server (sometimes highly significant).

Depending on the protocol, you might even be able to recycle cache entries - in
XMPP, if you oscillate between two avatars, the token for each one will always
be the same because it's just the SHA-1 of the data - but a simplistic version,
just storing the most recent avatar per account and its token, would be fine
(and in fact, this simpler approach is optimal for some other protocols, where
the token is just the timestamp of the last avatar change).

The more I think about this, the more I think we should have an avatar-caching
service that (unlike Connections) conceptually persists between sessions (in
practice, probably part of MC). Perhaps we could just take the code from
Empathy and bolt on a D-Bus interface, or perhaps we should think about it
properly as part of account management. It should store the avatars in ~/.cache
(freedesktop directory specification for the win) on PCs, but it should perhaps
offload the cache onto a replaceable SD card rather than irreplaceable internal
flash (if possible) on Nokia tablets.


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