[Telepathy] improvements to avatar and aliasing interfaces

[Dafydd Harries]

Earlier today there was a discussion on IRC about improving the
Avatar/Aliasing interface. Reposting here for further discussion.

Background: currently, if you request many avatars at once from Gabble, you
run the risk of the RequestAvatar calls timing out. At least, programs using
dbus-glib have a 25 second call timeout, which is easily short enough that
Gabble can't fetch avatars quickly enough for a reasonably small number of
outstanding requests.

Arguably, this should be fixed by having the pending call timeout increased.
The problem with this is that there is a limit, imposed by the bus daemon, on
the number of pending calls you can make concurrently.

Gossip avoids incurring timeouts by maintaining a queue of avatars to request,
and ensuring that there are only a certain number of RequestAvatar calls
outstanding at any given time. The drawback to this is that it introduces a
delay between receiving one avatar and requesting the next, which is
exacerbated by the fact that Gabble has its own internal queue of requests.
Ideally, we would like to have only one queue. The queue would be in the
connection manager, because the connection manager is best placed to decide
when to dispatch requests to the server.

Our preferred solution is as follows: add a method similar to RequestAvatar,
but that returns immediately, and causes a signal to be emitted with the
avatar data at a later point. Drawbacks: might wake up clients that already
have the avatar contained in the signal. This can be mitigated by
disconnecting from the signal when you don't have any avatar requests pending.

An extra benefit to this approach is that we can avoid a problem that occurs
when the avatar token changes between RequestAvatar being called and it
returning. Currently, it's ambiguous whether the avatar you've received is for
the old token or the new. By including the token of the avatar that we've
retrieved in the new signal, we remove any ambiguity.

Other solutions we discussed:

 - Have an API that creates a new D-Bus object for each batch of avatar
   requests; sucks because it complicates the API significantly.

 - Rather than including the entire avatar in the signal when it has been
   retrieved, store the avatar in the connection manager and request it with
   an additional method call; sucks because it requires the connection manager
   to cacha avatars.

Similar problems/solutions apply to GetAliases.

Thoughts?

-- 
Dafydd