[JDEV] Emoticons: guidelines

[Richard Dobson]

----- Original Message -----
From: "Dave" <dave at dave.tj>
To: <jdev at jabber.org>
Sent: Wednesday, April 24, 2002 3:22 AM
Subject: Re: [JDEV] Emoticons: guidelines


> I don't think the Jabber protocol itself should define that "standard"
> set.  Rather, we should let individual Web repositories develop, each
> with its own set of emoticons.  If j.o is the first one, there will
> be an incentive for any new ones to be compatible with it.  However,
> there are plenty of emoticons which aren't likely to make it into the
> j.o repository, and requiring clients to use a full URL for them seems
> somewhat unnecessary.  I'd much rather simply include multiple SRC
> attributes (or some other method of informing the receiving client of a
> location where it can definitely find an appropriate image, even if the
> receiving client doesn't have one in its own list of likely places (which
> probably include the hard drive, followed by the client developer's Web
> repository, followed by j.o, and maybe j.c, etc.), so preference can be
> given to the receiving client's own images when they exist, but there
> will be no need for a formal "standard" so _any_ emoticon can be sent,
> received properly, and decoded by the receiving client in whichever way
> it sees fit).
>
>  - Dave

Your method of having multiple SRC attributes combined with everything else
creates a massive overhead in the xml, and still you have not suggested a
way of stopping the sending client from sending all this extra xml and just
sending a bit of text instead, if you were paying for bandwidth by the k on
something like a GPRS WAP phone you do not want all this extra unnecessary
emoticon image tags in the xhtml section, because as noted before no matter
how much you may think they should, WAP phones will not render PNG images,
or GIF, or JPEG, only WBMP.
Also just because a client can accept xhtml it does not mean they can
display images (in the xhtml jabber spec support for the img tag is
optional) and so sending your massive multiple src image tags (of which
multiple src tags may crash clients which as per the html spec are only
expecting one src tag) is a complete waste of bandwidth, also as noted by
someone else even if a client does support images its possible that it will
not support remote http downloadable images (it depends on the client
writers implementation).