Re: [JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave


Richard Dobson wrote:
> 
> 
> > As you all saw, my initial proposal was purely receiver-based (i.e.,
> > the receiving program converted anything "interesting"-looking into
> > an icon), but it looks to me like you're all trying to figure out some
> > standard way of integrating non-text elements into messages :-(
> >
> > In that case, my proposal is simple - use an embedded element:
> > <message to="[EMAIL PROTECTED]">This is a <x xmlns="html"><img
> src="http://dave.tj:8080/icons/envelope.png"; alt="message"/></x> containing
> <x xmlns="html"><img src="http://dave.tj:8080/icons/2emoticons.png"; alt="two
> emoticons"/></x>.</message>
> >
> > Any new client (text-only or non-text-only) will be able to support
> > this quite easily, and any existing client won't be too difficult to
> > modify to accomodate this convention.  In other words, it has all the
> > advantages of HTML ... because ... ahem ... it ... well ... _is_ HTML ;-)
> >
> > Dave Cohen <[EMAIL PROTECTED]>
> >
> > Motto: Never invent anything you don't have to :-)
> 
> Thats all good in theory but what about people who are behind firewalls and
> proxy's?
People who are behind firewalls and proxies can upload their favorite
emoticons to GeoCities, and have their clients put in references to
there automatically.

> And what about the unneccessary bandwidth it takes up, not just in the xml
> but having to download those images,
Well, if you _really_ want to use whatever emoticon the recipient
already has (presumably, from his own Jabber client installation),
you can just use src="envelope.png" src="mail.png" along with any other
likely names the graphic is likely to have, and maybe include a default
src="http://somewhere/myenvelopeimage.png"; attribute, in case the guy's
client doesn't have any such icon.  This still prevents the formation of
a "standard" set of emoticons for Jabber, that all clients must support,
and whose interpretation (and therefore the implementation of the icons
by different clients) is guaranteed to lack uniformity.  It also means
that every time we add "standard" emoticons, clients without support
for that particular emoticon will be left in the cold.  We can always
have a "reference set" of emoticons at http://img.jabber.org/emoticons/
and have clients make hyperlinks referenced there by default, but we're
maintaining the capability for anybody to send any emoticon he may want
to send, without being limited by the "emoticon approval process" that's
going to develop if we try to standardize emoticons directly.

> for something like emoticons isnt it
> better just to have a way of defining that something is an emoticon and what
> it represents so particular clients can display emoticons that better go
> with a particular clients graphical style,
I demonstrated above that this isn't a concern if we use an HTML IMG tag
(since if the sender wants you to use your default emoticon for something
- i.e., it's not important that you see the exact same emoticon that
he sees when he composes the message - he can list a local (assumed to
originate on your machine) URL before the URL of his emoticon).

> and also whats to stop abuse of
> this by either embedding enormous images that take ages to download or an
> image with silly dimensions,
Karma stops many bad things in the Jabber world :-)
...and the silly dimensions problem can be solved client-side by anybody
who wishes to restrict the dimensions of incoming images.  I see no
reason to use an infrerior solution simply because the more general
solution requires a bit of protection on the part of the receiver.

> also i will cause problems where people use a
> lots of emoticons within a message,
Yes, I'm sure you will cause a lot of problems, sending too many emoticons
within a message ;-P
However, naming "standard" emoticons doesn't lessen the load on the
receiver's client's rendering engine - or even on his 'net connection,
if he doesn't store emoticons locally.  (Even a client that _does_ store
some emoticons locally is likely to reference another repository out
on the 'net, unless it decides to include some method for updating its
local repository whenever new emoticons are "standardized" ... or unless
the client developer decides to use update.jabber.org to broadcast
a "new" version of his client every time a new emoticon is added.
As you can probably guess, the situation has the capability of getting
rather silly.  I'd strongly suggest not trying to standardize within
Jabber something which isn't even a standard outside of Jabber: let
people go with whatever conventions they like, and the world will be a
much better place.  If the ISO ever decides to standardize emoticons,
I'll be the first to recommend using the standard in Jabber.)

> something like emoticons i dont think is
> best delt with by embedding it in this way.
Obviously, I'd tend to disagree ;-)

> 
> This is another good enhancement but I think is better for embedding images
> that are only going to be sent spairingly, like someone sending a picture of
> their cat or something inline in the im client, like the AIM image sending
> feature.
Well, if we're going to need this _even if we use "standadized"
emoticons_, we'll be opening this "can of worms," as you put it, anyway.
We might as well avoid having the "standardized" emoticon system
altogether, since it's strictly a slightly incompatible subset of the
HTML IMG tag approach.

> 
> 
> Rich
Dave

> 
> 
> _______________________________________________
> jdev mailing list
> [EMAIL PROTECTED]
> http://mailman.jabber.org/listinfo/jdev
> 

_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev