[Telepathy] Gabble avatars

[Dafydd Harries]

The Gabble avatars branch lives again!

http://projects.collabora.co.uk/~daf/monkey/telepathy-gabble-avatars-strike-back/

 - GetAvatarTokens([self_handle]) -> [""] :(

   However, if you ignore this and call RequestAvatar(self_handle), it'll
   work. Fixing this is interesting: I think Rob and I came up with a scheme
   for solving this, but I can't remember the details. Possibly the vcard
   manager should shove the SHA1 sum of our own avatar into the presence
   cache, but AFAICT there's still no way for GetAvatarTokens to know that
   there's already a request for our own vcard in flight (which automatically
   happens when we connect).

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

   I.e. Jabber doesn't specify mime types or min/max dimensions or max size,
   as far as I know. The avatars spec doesn't actually say what the CM should
   do if there are no requirements specified by the protocol.

 - SetAvatar

   Doesn't push presence with the SHA1 sum yet.

   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 emailed the
   Loudmouth list about this. If they don't change the API, maybe we should
   just bite the bullet and drop in another SHA1 implementation into Gabble.

   Furthermore, lm-sha.h is not installed with current loudmouth, so my branch
   fails to build due to lm_sha_hash being undeclared if you don't patch
   loudmouth first. (I sent a patch which fixes this to the Loudmouth list.)

   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.

   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?

With those caveats, it should all work. Client developers please test!

-- 
Dafydd