[Telepathy] Gabble avatars

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://projects.collabora.co.uk/~daf/monkey/gabble.avatars contains my work
based on Daf's avatars branch, which clears up some of the issues.

On Sun, 15 Oct 2006 at 03:47:07 +0100, Dafydd Harries wrote:
>  - GetAvatarTokens([self_handle]) -> [""] :(

Works now. On connection to the server, the vCard manager fetches our
own vCard (and sometimes edits it to include a better alias) - it now
emits got-self-initial-avatar, which is received by the GabbleConnection
and used to put our own avatar token in the presence cache.

>  - GetAvatarRequirements() -> ([], 0, 0, 0, 0 ,0)

Now gives some recommendations and pretends they're requirements, as I
suggested previously.

>  - SetAvatar
> 
>    Doesn't push presence with the SHA1 sum yet.

Now does.

>    Loudmouth's SHA1 code is not null-safe, so the SHA1 sums we generate aren't
>    correct (at least for images with nulls in them :))

I've incorporated a SHA-1 implementation taken from sha.sf.net (which is
the same one Loudmouth's is based on, I think).

>    The vcard manager interface is such that we can't modify the vcard
>    directly, as the edit method only supports string replacement values. I
>    think it's not orth changing that interface to accomodate avatars, though.

The edit method isn't actually called any more, since I did some
refactoring. Once I start work on vCard editing, I might kill off this
method, since I doubt it's general enough to cover everything we need.

>    I guessed wrong that the vcard request had failed if the callback was
>    called with error != NULL. In reality, the request has failed if vcard ==
>    NULL; you can have vcard != NULL and error == junk. Perhaps make it so that
>    one of the two is always NULL?

I think I've found the cases where this fails.

The remaining issues that I'm aware of are to do with other clients
simultaneously logged in on our account, which I also haven't really
tested yet:

Non-XEP-0153 clients
====================

If a non-XEP-0153 client (e.g. an older Gabble) is also logged in on our
account, we have to stop advertising the avatar, because we can't
guarantee that it won't change it without telling us, and we're not
allowed to poll the vCard. This is implemented. However, when all
non-conforming clients have gone away, Gabble doesn't detect this and
start advertising an avatar again.

This could be implemented as follows: when the last non-compliant client
goes offline, signal the vCard manager to re-download our own vCard;
when it arrives, have the vCard manager emit a signal with the SHA-1
which causes a presence cache update and (if the SHA-1 has changed) a
gratuitous presence broadcast.

Other XEP-0153 clients
======================

If another XEP-0153 client (e.g. Gajim or another gabble.avatars
instance) is logged in at the same time as Gabble, and it changes the
avatar, then we're meant to:

 * send a gratuitous presence update with an empty update child, which
   means "I support XEP-0153 but have nothing in particular to say about
   the avatar right now"
 * re-download our own vCard
 * in any presence updates before the new vCard arrives, use an
   empty update child again
 * when the vCard arrives, decode the photo and sha1 it
 * in any subsequent presence updates, use the sha1 we just calculated

I assume this is to defend against clients which calculate a wrong SHA-1?

At the moment I just trust that Gajim (or whatever) has got its sha1
calculation right, and start advertising that sha1 immediately. This is
technically a XEP violation.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFFN4ERWSc8zVUw7HYRAvH0AKCWBvEEIx5bveEixZkQtTkTh1EECACgo0jz
DAqqCu+YdS2oepCnFzUqoJ8=
=B6qi
-----END PGP SIGNATURE-----