[standards-jig] NEW: User Avatars (JEP-0084)

Tijl Houtbeckers thoutbeckers at splendo.com
Thu May 8 14:30:40 UTC 2003


Rachel Blackman <rcb at ceruleanstudios.com> wrote on 8-5-2003 12:25:42:
>
>>> - restrict PNG's to compression method 0 (deflate)
>>> - restrict JPG to standard encoding (as opposed to progressive 
>>> encoding) 
>> 
>> I'm not sure if we should go there.  Clients should not be required 
>> to do image checking or reformatting (well, unless they wish to use 
>> an unsupported  image format).
>
>I disagree.  I'm not sure it's necessary to limit to these functions, 
>but I think clients have to do image checking /anyway/ (or possibly 
>reformatting) because of the MUST qualifier on the image dimensions 
>(between 32 and 64 in each direction) and image size (8k).  Why not 
>keep them to sane minimums for the format as well, since you already 
>have to be doing the checking? 

The point of limiting yourself to these two image formats with these 2 
formats and these 2 restrictions is that basically every jabberclient 
with some kind of display can fully support avatars. However, if you'd 
have to support more then method 0 (but practically every PNG is 
anyway) and progressive encoding that would be a lot harder. Method 0 
and standard encoding are also most often natively supported. Mandatory 
support for MNG/animation or throwing in an extra obsoleted graphics 
format such as GIF also doesn't make it easier. This is what I meant 
with being "truly" being crossplatform. 

Do note that I meant these encoding restrictions to be a 
recommendation, even I am not in favor of making them mandatory. If 
HappyWinClientA quickly wants to add some avatar support I don't demand 
that they have to crawl around looking in the headers and converting 
image files. If they selected a progressive encoding JPEG then that's 
too bad for those that can't see it. But, the more advanced clients, as 
for example clients that already convert other formats to JPG or PNG, 
can handle the encoding conversion within formats as well. Also 
components (or clients) that autogenerate images could take these 
restrictions into account, so as many clients as possible can see them. 
(For example, AIM transport converting those nasty GIFs for us) 

>>> As for animation, wether MNG or GIF or something else, I think it
>>> should be a seperated from the static image.
>> 
>> I say that if MNG is acceptable for the JEP, then there should be no 
>> need to  have a separate 'animated' entry.
>
>This, I agree wholeheartedly on.  Plus, if 'animated' stuff including 
>Flash were allowed, you just KNOW someone would put together a Flash 
>avatar with irritating noises.  And then we'd have people seeing red 
>and foaming at the mouth over it, and there'd be a bloody rampage, and 
>it'd be generally unpleasant. ;)

The idea was that every client would publish an avatar that everyone 
can read, and that based on disco it could select more advanced avatars 
for other clients. For example, if I would have to choose the best 
format for desktopclients for both static and animated icons it'd be 
SVG not MNG, but it's unreasonable to expect SVG support from clients 
as this point. (let alone my mobile clients). One avatar that 
*everyone* can see, and one (or more even?) for the bleeding edge MNG, 
SVG, Flash etc. hungry crowds.. 

Ofcourse, I *also* want my flash-avatar to turn into an adbanner on 
mouseover to make a few extra euros ;) 

just my 0,02 euro of advertising revenue...

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list