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.. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
