[Telepathy] Avatar interface proposal

Andre Magalhaes andrunko at gmail.com
Thu Jun 8 06:24:18 PDT 2006


On 6/8/06, Raphael Slinckx <raphael at slinckx.net> wrote:
> On Thu, 2006-06-08 at 09:40 -0300, Andre Magalhaes wrote:
> > 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.
> [snip]
>
> While i think the proposed API with the changes is reasonable, don't you
> think this is a major abstraction leakage ?
>
> I know that for practical purposes (imposed by jabber's supposedly
> broken implementation only) it is easier to do it this way (having the
> client do the dirty work).
>
> Still, i think the telepathy API shouldn't reflect that problem, and
> that the 'workaround' should be implemented in the jabber connection
> manager, to be one day removed when jabber gets fixed (read: never).
>
> That implies that the jabber connection manager has a state containing
> old avatars and that it can do the matching against new hashes and all,
> to finally emit a new avatar signal.
>
> Also, does anyone have any insight about how other protocols work, do
> they make the same mistake as jabber, or do they work correctly ?
> Maybe it will be actually more difficult to bend correctly-behaving
> protocols to the twisted xmpp behavior leaked in the spec ?
That is one approach, let the connection manager do the hard work, and
emit the AvatarUpdated signal only when the avatar really changed,
even between sessions. But this would require the connection manager
to have write access to the disk, in order to store the avatar images,
which IMHO i don't think it's a good idea.

BR
Andrunko


More information about the Telepathy mailing list