[JDEV] Emoticons: guidelines

[Dave]

Yup, I just read through all of the above, and now I'm beginning to think
that maybe Jabber shouldn't implement emoticons at all.  People send
emoticon-containing emails even though plain-text email doesn't support
'em directly; why should IM?

That said, I _would_ ask the transports to translate emoticons if we're
going to use any emoticons, because there's no simple way for your client
to tell whether somebody at aim.dave.tj is behind the AIM transport at
dave.tj, or whether he's an actual user on the Jabber server aim.dave.tj -
saddling the client with such detective work is not only unclean (because
it means that the transport is _not_ the only thing that needs to be
updated when external networks change), but also quite ugly for the
clients (since the transport is in a much better position to figure out
what should be translated than the client - especially if we assume that
the client knows nothing about the AIM network, which was the general
goal behind Jabber in the first place).

XHTML is a very easy implementation, because it just treats emoticons
as images (which is really what they are).  If we're going to start
classifying images into different categories, we should probably have
a logo standard, so :logo-IBM: should produce an IBM logo image, etc.
We can also have an artwork image type, where :art-picasso: would instruct
the receiving client to replace that text with a random Picasso painting
(in whatever crazy format the device happens to support).  Obviously,
we shouldn't stop there - having an album-cover image type is absolutely
necessary (if we don't want the RIAA to sue our pants off, and then
we'll need a special image type for pantless people - maybe :porn: or
something like that?), so a client seeing :albumcover-beatles: would
have to dig up an image of a Beatles album cover.

 - Dave


David Sutton wrote:
> 
> If I can make a suggestion:
> 
>    I would look back at the room logs for the JDEV conference room over 
> the last week, where there has been many discussions on this topic 
> looking at many different angles, including a whole evenings worth. Adam 
> Theo (theoretic.com) has also set up a wiki page discussing this. I'm 
> noticing some of your ideas are going to get slammed from other 
> discussions i've been involved it, and it might be best to make sure you 
> are aware of all the other things that have been said.
> 
>    My personal oppinion is that this should be client side only, with 
> the client doing any of the clever manipulation, as the client knows 
> what protocol the end user will be using, and I feel that transports 
> should be simple routers which take a message, encapsulate it in 
> whichever protocol is necessary, and send it on to the end client. If 
> you want to come up with some special scheme which will work between 
> jabber end clients, then fine - just don't then force this scheme onto 
> messages intended for non-jabber users, as it will be the transport 
> writers and maintainers who get slated with all the emails about how 
> transport xyz isn't working as 'it should do' (a purely relative statement)
> 
> Regards,
> 
>    David
> ---
> David Sutton / Peregrine
> jid: peregrine at jabber.sys.legend.net.uk
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>