[Bug 20035] Avatar cache reference implementation

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=20035

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-20 06:46:54 PDT ---
(In reply to comment #8)
> 1b) not found in cache: avatar is requested from CM. When CM emits
> "AvatarRetrieved" then TpContact::avatar-retrieved is emitted with the data in
> memory (no need of using g_signal_has_handler_pending since it is cheap to just
> pass the data pointer)

Don't signals copy the data anyway, if you're using boxed types correctly?

> 2) The avatar filename could be kept inside TpContact, and could be returned
> any time using tp_contact_get_avatar_filename() but is reset to NULL each time
> the token is modified. If avatar-filename is NULL then the user knows he has to
> first call tp_connection_request_avatars(). If it is known to have no avatar
> then filename is "" (to be consistent with "avatar-token").

The cache should also store the MIME type from the CM, and this accessor should
return it. CMs give you the information, please don't just throw it away :-)

> In the case we retrieved the avatar from CM, we have already the data in
> memory, so I don't want to return only a filename, otherwise it will read from
> disk again.

On a competent OS (e.g. Linux), is reading from a file you just wrote actually
much more expensive than memcpy?

> I could then create a GMemoryInputStream but that means I have a
> dup the data in memory because the GArray is feed when returning from
> AvatarRetrieved.

Don't you effectively have to duplicate it (at least once) regardless, either
by copying the GArray or by saving/loading a file?

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