[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

Tijl Houtbeckers wrote:
> 
> Hi dave, 
> I've read almost all your posts on this subject,
Wow ... I'm impressed :-)

> 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..
Grrr >:{
I think your approach below is way too lightweight, and skimps on some
crucial issues that'll come back and bite us later.

> 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)
It's what I call "selective HTTP downloading:" the receiving client
downloads an image if it doesn't already have an appropriate one
(or decides to display the ALT string, probably dependent on user
preferences).

> 
> 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.
I would tend to disagree.  Just read the introduction to the Jabber world
on www.jabber.org and you'll see what I mean - the spirit of Jabber is
_not_ to burden clients with the curse of having to deal with stupid,
proprietary, good-for-nothing IM systems.

> 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 ;)
Well, somebody's gotta do the dirty work to talk to a dirty network,
and the transport is the entity whose job it is to do just that.
I'd consider any transport writer who doesn't want to do the same
regexp-matching sillyness that the MSN client must do (and that the
MSN-t must therefore replicate, in order to be compatible with MSN)
to have come to the - rather correct, IMHO - realization that MSN just
plain sucks, and probably shouldn't be supported at all.  If we're going
to support external networks, though, we should do it right; having a
lazy transport that simply dumps the raw data from the MSN network on our
poor Jabber client is really cheating, IMHO, since it's dumping part of
the MSN-t's job on the client - exactly what Jabber was intended to avoid.

Think of it: if you're going to have to reimplement half of the
functionality of each proprietary IM client when you create a Jabber
client, aren't you going to ask what the advantage of coding a Jabber
client (as opposed to an MSN Messenger clone) is?  You might as well just
write a Trillian-like program, and not have to deal with half the Jabber
transports constantly being down, and the other half getting IP-blocked.

Besides, judging by the quality of existing Jabber clients, I'd say
the load on our Jabber clients is way too high.  Adding an extra burden
which should be handled by any self-respecting transport to the clients
is antithetical to the whole Jabber concept - and it won't help anybody.

> (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.
Read through the intro to the Jabber mentality at j.o ... I think
you'll agree that the general idea is for the client to be as isolated
as possible from the implementation of external networks.

> 
> 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.
If you want to use graphical emoticons, you should be able to support
HTML formatting quite easily.  I'm actually toying around with the
possibility of using the rendering engine in emacs w3 to render XHTML
messages in "plain text."  Anybody with graphics has no logical excuse
not to support XHTML, as far as I can see off-hand.

> IMHO emoticons aren't such seperate items.. they're just part of writing.. 
Okay, I see two very different schools of thought emerging here: either
emoticons are "just part of writing," and don't need _any_ special
support from the Jabber protocol, or they are rather seperate entities,
and deserve their own XML elements.  You folks really have to make up
your minds before we can argue about implementation :-(

> 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.
Why should Jabber invent its own guidelines to compete with MSN?  We might
as well use the crappy MSN system - at least that way, we'll be compatible
with another IM system with a substantially larger user-base.

> Stripping off all other XHTML to 
> find a few emoticons is a step to far for me though.
That's all done by your XML parser.  I don't mean to include all
formatting-type tags in the plain-text portion of the message - rather,
I mean to include only embedded-object-type tags there.  (That's another
reason why I think it'd be cleaner to define a seperate XML namespace,
and have emoticons be objects in it.)

> 
> 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.
Just because people do things in this way, don't assume it's a good way
of doing things.  XML (the foundation of Jabber) major advantages in this
regard over other IM systems, and following the herd of other IM systems
nullifies most of those advantages.  The text between those body tags was
not meant to be parsed; it was meant to be treated as what it represents -
real text.  Having our standard dictate _how_ to parse it (implying that
it obviously _should_ be parsed) would be a very bad precedent.

> 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.
Please see my above note.

> Wether or not to 
> suppoert property IM systems like MSN is left up to the developer himself,
...so Jabber clients are no longer only talking to the Jabber network,
but rather translating to/from other networks :-(

> and the 
> transport maintainers can focus on more urgent matter :)
Yup, the Jabber project lacks manpower.  If we had more people working
on the transports, we wouldn't have to push the transport functionality
onto the poor clients.

> (If you say that you can't 
> know wich transport is actually MSN etc. Well, my client has to figure that out 
> somehow anyway
Why is that???

> (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..)
...so your client can tell the difference between the MSN user
go at hotmail.com on your msn.dave.tj transport and the Jabber user
go%hotmail.com on the Jabber server msn.dave.tj?

> 
> Switching current clients over to the new guidelines will be easy..
That stands to reason - current clients already do things in a non-XML
way, because that's the only way they know (following the herd of other
IM systems).

> and maybe we'll 
> have a chance that soon in the future because of these guidelines different clients 
> remain/become interoperatable with each other. :)
With any type of real XML standard, clients will _very quickly_ become
interoperable, because all the "parsing" work is already being done by
their libraries, so they don't have to do crazy regexp-matching.

> And I'd love having a simple X 
> element telling that the current message should not be parsed for emoticons..
With proper XML emoticons, we don't need that kludge, either.

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