[JDEV] Buddy Icon (Avatar) Proposal

temas temas at box5.net
Thu Aug 30 19:59:35 CDT 2001

Julian Missig wrote:

>Replies within.
>----- Original Message -----
>From: "Jens Alfke" <jens at mac.com>
>To: <jdev at jabber.org>
>Sent: Thursday, 30 August, 2001 19:37
>Subject: Re: [JDEV] Buddy Icon (Avatar) Proposal
>>On Thursday, August 30, 2001, at 03:52 PM, Julian Missig wrote:
>>>First, the requirements on the image.  The image should be a 50 x 50
>>>image in either GIF, PNG, or MNG format, as well as under 8k of data.
>>>MNG support is optional.
>>(1) 50x50 seems an unusual choice. Mac and Windows use 32x32 heavily
>>(what do kde / GNOME use?), NeXT used 48x48, and Mac OS X also supports
>>64x64 and 128x128. (Apple's OS X Mail client displays a 64x64 icon of
>>the sender of an email message, and my Jabber client uses 32x32.) It
>>would be better to have a size that was a power of two so that it would
>>scale more smoothly to 32x32. OS X has built in bicubic scaling so it
>>won't look too bad, but without this the icon will look really jaggy at
>>32x32 or 64x64.
>50x50 is what AIM uses. The point of this was to easily support AIM's Buddy
>Icons as well.
>>(2) Why disallow JPEG? It has by far the best compression. (A 64x64 face
>>image usually compresses to under 2k.) It's only drawback is the lack of
>>alpha channel.
>It didn't seem worth it to support JPEG. When images are that small, most
>people don't want them lossy to begin with.
>>(3) What is MNG? I've never heard of this before.
>Animated PNG.
>>>The actual icon request is in a new IQ namespace:
>>Why not use the server-side generic storage facility instead? The get
>>sequence would be just as you described, except the namespace would be
>>something that didn't start with "jabber". The owner of the image would
>>use a "set" on his/her JID with the same namespace. This way the server
>>would automatically store the image.
>This way icons can easily be changed when presence changes. I could very
>easily have one icon for available, one for away, one for dnd, etc.
>>This would reduce network traffic for the owner of the icon (imagine the
>>poor guy on a 28.8 modem with 100 buddies who all request his new icon
>>at once) and allows an offline user's icon to be retrieved.
>>>        <data type='gif|png|mng'>
>>>          Base64 Encoded Data Here
>>>        </data>
>>It's not really necessary to declare the type of the data, as the
>>standard graphics formats are all self-describing. But if you do provide
>>it, please use a real MIME type instead of making up a name.
>Yeah, it would make more sense to use the MIME type... the data is base64'd,
>in some cases it may be easier if the type is known ahead of time.
>jdev mailing list
>jdev at jabber.org
Alrighty Julian and I talked some more.. here is our new proposal (hope 
he isn't sending this at the same time I am).  48x48 icons... I'll just 
scale down aim's no biggy.  We'll drop MNG for now, since barely anyone 
implements it and add JPEG.  Finally the type attribute is nuked, it's 
wasteful and probably pointless like you said.  So last issue is the 
public XML.  We had considered this early on (at least I had) but the 
problem was it wasn't widely implemented (read, only jabberd does it). 
 I'm not overly opposed to just saying that's the way it'll be done, 
because it does have large performance gains, but I want to discuss it 


More information about the JDev mailing list