[JDEV] Emoticons: guidelines

[Dave]

Julian Fitzell wrote: > > Dave wrote: >  > Okay, it's a 2 vs. 1 here
... how about if one of you echoes _my_ >  > messages instead of the
other's?  That should even things a bit ;-) >  > >  >  - Dave
> 
> If we're going to start counting here, you can put me down for another 
> one against - I don't like sending img tags in the message.  But I feel 
Okay, so now it's 3 vs. 1 ... you'd think more people would support an
XML-based system for including entities in an XML protocol, rather than
asking clients to do complicated text processing to extract entities :-(

> like we're going in circles here.  I don't think you need to take it as 
> a personal attack that others are arguing against your proposal... but 
I do need to take it as a personal attack.

> there doesn't seem to be a lot of support for it in the messages I've 
> been reading.
Yeah, Democracy kinda sucks, eh?

> 
> I personally have the following issues with it:
> 
> 1) I don't like html-ish tags being stuck directly in the message tag... 
> they're hard to filter out if you don't want them.
You simply instruct expat to ignore everything from an open html
tag until the corresponding close tag - a lot simpler than doing an
s/\b:(\w+):\b/\1/g on every incoming message.

>  If you want to do 
> this, do it in the xhtml tag where it is only dealt with by clients that 
> understand images.
Any client that can do emoticons can do images.

> 
> 2) I don't like using filenames to identify an emotion.  Some picture 
> that somebody thinks I want to see (maybe some nice porn) does not 
> necessarily convey an emotion to me.
...then use relative URLs for your emoticons (and consider having your
client treat incoming URLs as if they were relative, and only fetch the
remote version if you don't have a local version) :-)

>  I want to learn what an image 
> means in my client.  And I want my emoticons to have the same style and 
> a style that matches my UI.  And I don't think sending relative paths in 
> the SRC attribute is a good solution to this... one client may not be 
> using .png files so why should it have to look for smiley.png as a key 
> to display it's happyface image?
Your client can s/.png/.gif/ the URL if you really hate open standards ;-P
Rejecting an open standard (URLs) because some clients refuse to support
open standard image formats is throwing the baby out while leaving the
bath water :-(

> 
> I think the simple solution is to just leave it up to the client (with a 
> list of suggested emoticons to support, if desired).
All I can say is "Yuck" :-(

>  This works fine 
> except for the weird ones that MSN uses.
MSN has its own problems.  If the MSN transport wants to translate
between XML and Microsoftese, that's its own choice, but we shouldn't
let Microsoft make decisions about our open standards.

> 
> The nicest solution I've seen is the one that allows you to define "(*)" 
> or ":star:" or whatever you want as being a star emoticon (is that 
> really an emoticon?  no emotion there... bloody Micros*ft).  This  gives 
> the following benefits:
> 
> 1) the MSN transport could add the appropriate tags to messages from the 
> MSN network so Jabber clients could translate it.
That approach works just fine if we treat emoticons as full-fledged
XML elements.

> 
> 2) Jabber clients can use the ":star:" instead which can still be 
> translated by the MSN transport (since it knows ":star:" represents the 
> star emoticon), can be properly displayed (by the end user's 
> preferences) in another graphical Jabber client, and reads in a way that 
> makes sense for text-clients.
In other words, text clients are an afterthought. . .

>  This also allows you to use :etoile: 
> instead if you are speaking in french.  Yes I know it doesn't do the 
> translation for a french speaker talking to an english speaker...
...and in the case of non-English speakers on text clients, all they've
gained is these silly colons before and after words they can't understand
... I believe the proper gentleman's reaction here should be somewhat
along the lines of "This sucks!"

> but 
> you know what?  If it weren't for the system they would have just had to 
> say "etoile" or "star" in text in the first place.
If we use real XML elements (rather than trying to encode them directly in
the text), their clients can do whatever they want with them (including
the possibility of simply displaying :etoile: or whatever, if they're
working with text-only clients and just can't get over those stupid
colons before and after the words).

>  (but please let's 
> not use :luv: - one character saving is not enough for me to stare at 
> that all the time)
LOL. . .

> 
> Obvious disadvantage here is bandwidth usage for some clients.  This is 
> really an issue of feature negotiation which needs to be resolved by 
> other JEPs.  Obviously if you are using an x namespace here then once a 
> feature negotation standard is decided you can query for support of that 
> namespace.
If we're going to define a seperate namespace for this whole
text-clobbering ordeal, we might as well avoid messing with the actual
text of the message, and use _real_ XML elements to mirror our entities
(emoticons, in this case).

>  But we have the same issue with the double inclusion of an 
> <xhtml> and <message> tag in a message... all these things need to be 
> able to be turned off if we want the protocol so be as small as possible 
> for certain clients.
That has nothing to do with our emoticon issue, so let's avoid it here.
(You don't want more discussions here cluttering your inbox, do you?
...so don't provoke it. . .)

> 
> I hope we can return to some constructive discussion.  I don't even care 
> much about this issue myself, but I'm getting a little tired of the 
> circular conversation and "you said I said 'foo' but I didn't", "yes you 
> did", etc.... that has been filling my mailbox from this thread.
LOL ... it's been filling my mailbox, too ;-P

> 
> Returning now to spectator mode.
...so does that mean it's only 2 vs. 1 now?

> 
> Cheers,
/me likes to cheer, too ;-)
> 
> Julian
Dave

> 
> 
> -- 
> julian at beta4.com
> Beta4 Productions (http://www.beta4.com)
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>