[standards-jig] NEW: User Avatars (JEP-0084)
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
>> 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...
Software Engineer @ Splendo
More information about the Standards