[JDEV] Emoticons: guidelines

Tue Apr 23 19:17:05 CDT 2002

Hi dave, 
I've read almost all your posts on this subject, and though you make an intresting 
point that XML is a much more flexible system for embedding all kinds of information 
in your messages I still think your approach to the subject is way to heavy..
Though you came with a variaty of different solutions they still epend on one or more 
of these things:

HTTP downloading: not done for small footprint jabber clients, such as mobile clients.. 
privacy/hosting concerns. (though I see you stepped of this idea)

Transport translating/transforming of messages: if I'd be maintining one of the 
transports, the last thing I would care about is translating of emoticans, the 
transports job is to route the message, not interpretate it. Even if you do make it to 
some kind of standard I think transport maintainers will agree with me on this one. 
That "silly regexp-matching kludge" does not belong in a transport ;) (So no I do not 
think it's a transports job to make other networks "look the same to the client as 
native Jabber users". Their job is to route messages and precense into the jabber 
network.

Requiring the parsing of XHTML to support emoticons: manny simple clients do not 
look at the XHTML namespace at all, yet maybe they still want to make use of 
emoticons. IMHO emoticons aren't such seperate items.. they're just part of writing.. 
and my client can make them look a bit more pretty if it likes (or I like it to). I can make 
my mobile client support a few simple emoticons by just parsing what's inbetween 
<body>and</body> easily.. If there's be a guideline somewhere of wich symbols are 
commenly used for emoticons in jabber I'd follow it. Stripping off all other XHTML to 
find a few emoticons is a step to far for me though.

Wich brings us back to the root of the problem.. currently there are several client who 
make use of this (parsing body text), but they're not all doing it the same. Wich is why 
there should be a *guideline* (like it says in the topic) on wich emoticons are 
available and useable in all clients that would follow these guidelines. Wether or not to 
suppoert property IM systems like MSN is left up to the developer himself, and the 
transport maintainers can focus on more urgent matter :) (If you say that you can't 
know wich transport is actually MSN etc. Well, my client has to figure that out 
somehow anyway (I just look for wich one is called "msn" right now), since I want to 
use the MSN nickname the transport supplies in the <state/> tag of precense 
information..)

Switching current clients over to the new guidelines will be easy.. and maybe we'll 
have a chance that soon in the future because of these guidelines different clients 
remain/become interoperatable with each other. :) And I'd love having a simple X 
element telling that the current message should not be parsed for emoticons..