[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

Richard Dobson wrote:
> 
> ----- 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,
It's not a massive overhead at all, once you consider the overhead
of sending _any_ emoticons at all with your method.  At least with my
approach, each emoticon is self-contained, so there's no need for the
emoticon definition sillyness with that x attribute to go along with
every message.

> 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,
What???

> 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,
Your very uncapable GPRS WAP phone makes up a tiny percentage of the
IM market at the moment, so having today's wireless phones dictate
tomorrow's IM standards is just plain ludicrous.  That said, there's
nothing stopping your wireless phone from doing s/.png/.gif/ on the local
URLs (as I already mentioned before), so you can store all your emoticons
locally, and use the ALT attributes of anything you don't have locally
(to conserve your KB).

> 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.
See my comment above.

> 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).
Can you try sticking to one subject per sentence?

Anyway, yes, a client can certainly render HTML without images.  As for
the IMG tags, a text-only client will simply take the ALT attribute,
which can be made a lot more meaningful than ":etoile:" or whatever.

Multiple SRC tags don't crash lynx, one of the oldest browsers still
in use.  They certainly shouldn't crash anything newer!

Sending the IMG tag if the client is only going to look at the ALT
attribute is _not_ a complete waste of bandwidth, especially if the
sending client first checks whether the receiver supports images and
sends plain text otherwise.

> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>