[Bug 33410] Do on-disk avatar cache in CM

[bugzilla-daemon at freedesktop.org]

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

--- Comment #29 from Xavier Claessens <xclaesse at gmail.com> 2012-07-11 12:22:13 PDT ---
(In reply to comment #26)
> + <p>Request avatars for a number of contacts.</p>
> +
> + <p><tp:member-ref>AvatarsUpdated</tp:member-ref> signal is emitted when
> + avatars are retrieved. It is not mandatory to wait for all avatars to
> + be retrieved before emitting this signal, avatars could be signaled in
> + multiple batches, or even for each contact separately.</p>
> 
> Those aren't the semantics we give to "request" everywhere else in tp-spec
> (e.g. in RequestContactInfo). ContactInfo calls this operation "refresh"
> (RefreshContactInfo), please do the same here.

Good point. Renamed.

> Please don't imply that AvatarsUpdated is guaranteed to be emitted - for
> contacts whose avatar we already knew, it shouldn't be emitted if "we were
> already right about it".

Done.

> I think we should have a special case wherever cache URIs appear: "" means "no
> avatar that this protocol allows us to see" (as distinct from "I don't know").
> Or maybe "file:///dev/null" if you prefer :-)

"" URI means the contact has no avatar. "I don't know" is represented by
contact attribute missing from the GetContactAttributes call. That's already
said in the spec. Or do you mean something else?

> Do we want a RequestAvatar(u: Handle) -> s: Cache_URI, suitable for Contact
> Information dialogs, which does wait for the round-trip? (Analogous to
> RequestContactInfo).

We could. It can also easily be added later if we actually need it.

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