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

Tue Jan 22 05:32:46 PST 2008

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

--- Comment #13 from Alberto Mardegan <mardy at users.sourceforge.net>  2008-01-22 05:32:46 PST ---
(In reply to comment #12)
> Mardy: we appear to be in violent agreement, and what you're talking about in
> the last comment is fine. Gabble already holds avatars in RAM, and ptlo
> recently fixed it to be able to reply to multiple requests with one
> AvatarRetrieved signal.

How does this work? Does it mean that the emission of the AvatarRetrieved
signal is delayed by some time (how much?) to see if other RequestAvatars calls
are made?
We are not in violent agreement :-) My last comment was about implement caching
in order to second Mikhail's idea of a LookupAvatars method.
Anyway, even with ptlo's optimisation, we are incurring in some performance
penalty, i.e. avatars are not advertised to the UI as soon as they could.

Maybe it's a very small delay, but I'd say that in any case it's a symptom of a
broken API.

> For the record: in the current design, other CMs SHOULD cache (at least a few)
> avatars during the lifetime of the Connection (to avoid repeated round trips to
> the server), MUST NOT cache avatars beyond the lifetime of a Connection (CMs
> shouldn't be stateful beyond a Connection's lifetime - that's an invariant of
> our API), and SHOULD NOT rely on being able to save avatars to the filesystem
> (they should cache them in RAM).

Fine.

> If you still believe the API is unworkable, bring it up with Rob, but please
> implement it anyway. I don't think re-badgering the Avatars API takes priority
> over everything else API-related that we're trying to work on (notably, MC).

It's not unworkable, it's just creating performance problems: either we get too
many signals, or the avatar retrieval is delayed with caching.

The more I think of it, the less I can find a reason not to have the avatar
data in the AvatarUpdated signal: with the current API, of those clients
receiving it, there will be at least one which will call RequestAvatars, with
the result that all the avatars which received the AvatarUpdated will also
receive the AvatarRetrieved, unless they disconnect from the D-Bus proxy; so,
why not bother them only once? This would also simplify the API a lot.

Could we violently agree on this? ;-)

About implementing the current API... If other CMs are not implementing the
deprecated API, I guess I'll have to implement the new one in MC; but please
don't consider this as a reason not to rework it, as IMHO there are lots of
ways to improve it (and my suggestions might not be the best ones).

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