[JDEV] Emoticons: guidelines

[Dave]

My outgoing mail reformatter normally does "the right thing."  I guess it's having a bad day, today :-(

Fortunately, I think I may know what's wrong ;-)

 - Dave


Dave wrote:
> 
> 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
> > 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>