[JDEV] Emoticons: guidelines
Dave
dave at dave.tj
Mon Apr 22 20:37:50 CDT 2002
Reply inline:
- Dave
David Iodice wrote:
>
> here's something to ponder:
Oh, no ... not _another thing_ to ponder ... please ... I'm already busy
pondering Mr. Dobson's assault on HTTP IMG tags ;-/
>
> emoticons can be viewed as a special case of a more generic
> capability. Let's call it "jabsters" (c). In essence a
> jabster is a textual description that has a meaning
> different from the text itself -- a "short cut" if you will.
> Emoticons are one example, all of the other little acronyms
> like BTW, IANAL, TIA, RTFM are short cuts too (but they
> aren't emoticons). If I type BTW, what can't it come up as
> "By the way" on the other client?
This should all be handled _only_ by the receiving client. When it
receives "LOL," it can translate that into "Laugh Out Loud." It can
also translate ":-)" into a smiley (and ":)" into a noseless dude
making a half-hearted attempt at smiling), or it can give you a
"tooltip" when you hover over RTFM with your mouse saying "Read The
F'in' Manual!!!" However, none of this has to do with our protocol
for emoticon representation (and indeed, none of it belongs in any
particular IM protocol suite, for reasons I've already outlined - we
lack the authority to standardize this sort of stuff ... if we keep
trying to abuse a monopoly we don't have, we'll end up like Apple).
>
> I suggest that we have a more generalized format to
> accommodate other short-cut uses. We also need a mechanism
> to identify which jabster "sets" are available on each
> client (a capabilities exchange). We don't want one person
> typing LOL on a client assuming it will come out as
> "laughing out loud" and the other client uses a different
> jabster set that translates LOL to "lots of luck".
Something about the above screams "complexity," at least IMHO.
>
> A more esoteric application can be for the non-tradition IM,
> like from human-to-device. Perhaps I want to IM my coffee
> machine and say "Turn On". The coffee machine could see
> this as a jabster and translate it to the relevant command
> string for the device. Here the jabster is a translation
> from a human readable command to a device command.
>
> Similar to emoticons? I think so. So when we finalize how
> we want to handle emoticons, lets also think about the more
> generic case and perhaps cover it, too while we are at it.
Ideally, the coffee machine's Jabber client would understand the "turn
on" command and translate that into whatever language it uses to turn
itself on (it can show itself pictures of women sans clothing, for all
I care), but once again, we're out of the realm of what translation
algorithms belong in an IM protocol. The whole idea behind IM protocol
standardization is that everything external adapts itself to the protocol
without all sorts of built-in translation within the protocol itself.
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
More information about the JDev
mailing list