[Telepathy] Avatar interface proposal

[Andre Magalhaes]

Hi,

On 6/7/06, Rob Taylor <robtaylor at floopily.org> wrote:
> I would say:
> GetAvatarId (u: contact ) -> s: avatar_id
>
> The avatar id should be a unique, or statistically nearly unique
> identifier for a given image. It should also be valid over multiple
> sessions. e.g. a hash of the image data.
Right, my fault. What i was thinking when i put the id as an unsigned int :P.

As we discussed on the #telepathy, this identifier MUST be unique even
between sessions. See what happens on XMPP using Vcard based Avatars.

1 - Someone publish the avatar image using the vcard-temp
2 - After this all presence broadcasts will contain a element
indicating the sha1 hash of the image data. This element will be sent
even if the avatar did not change.
  <x xmlns='vcard-temp:x:update'>
    <photo>sha1-hash-of-image</photo>
  </x>
3 - The other user checks if the avatar stored is the same avatar
avatar refered by the hash. If yes, it just ignores, if not, it
request to get the new avatar.

Now see our approach of this:
1 - The user boots the UI (or whatever will show the users avatar)
2 - The user requests the avatar id for all contacts
3 - Then he checks if the avatar stored is updated, by comparind the
avatar_id with the id stored. If yes, just use the avatar stored, if
not, use GetAvatar to get the new avatar image

Ps.: Note that the if some contact changed the avatar image between
connections, it's up to the UI to know it and check if the old avatar
stored is updated. No signal AvatarUpdated will be emitted between
sessions. If on the same session some contact changes the avatar
image, a new signal AvatarUpdated will be emitted containing the new
avatar unique id.

> I've made this s: here for enough significant bits ;)
>
> >        Parameters:
> >        contact - an integer handle for the contact to request the avatar
> > for
> >
> >        Returns:
> >        SHA1 hash of the avatar image data itself
>
> Unique id. I don't think its necessary to specify the type of hash -
> especially as we don't specify the image format ;) ;)
Yeah, its really not really necessary as the user will just check with
the stored id. I just used the type of id described on JEP 0085.

>
> >        Possible Errors:
> >        Disconnected, NetworkError, InvalidHandle, PermissionDenied,
> > NotAvailable
> >
> > GetAvatar ( u: contact, u: avatar_id ) -> s: avatar
>
> this should be
> GetAvatar ( u: contact, s: avatar_id ) -> ab: avatar
Great. I didn't know about ab actually.

>
> >        Get the avatar for a given contact.
> >
> >        Parameters:
> >        contact - an integer handle for the contact to request the avatar
> > for
> >        avatar_id - SHA1 hash of the avatar image data itself
>
> see above.
>
> >        Returns:
> >        A Base64 encoded avatar image
>
>
> The image *does not* have to be base64 encoded, you can send binary
> blobs over DBus as an array of bytes. base64 encoding just wastes time,
> memory and power ;)
Again, i just used base64 encoded image, cause XMPP already uses it.
If we don't use it, the connection manager will have to decode it
before sending it on the bus.

> The format of the image needs to be specified - is this raw 32bit rbga?,
> jpg, png? or do we actually want to put a mimetype in there? The answer
> to this isn't obvious to me.
I completelly forgot that we have other systems that may need the
mimetype to load the image. GdkPixbufLoader can deal with this. But
yeah, we need a new parameter identifying the image mimetype.

BR
Andrunko