[Bug 20035] Avatar cache reference implementation

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Apr 20 16:09:49 CEST 2010


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

--- Comment #10 from Xavier Claessens <xclaesse at gmail.com> 2010-04-20 07:09:49 PDT ---
(In reply to comment #9)
> (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?

Not if you give a G_TYPE_POINTER

> > 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 :-)

Yep, my implementation also cache mime and return it. That's already done ;)

> > 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?

Maybe I'm just trying to do exessive optimisations... As avatar data is
something that could be big and we can have a lot of contacts, I'm trying as
much as possible to just pass the data pointer instead of alloc new memory and
copy. Feel free to object and tell it's fine to only give a filename and
listeners will just read again from file.

> > 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?

g_memory_input_stream_new_from_data() takes ownership of the data, it does not
dup it. So if we use it with sync calls inside AvatarRetrieved callback then we
don't have to copy the data... but that's insane.

-- 
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.



More information about the telepathy-bugs mailing list