[JDEV] Emoticons: guidelines

Wed Apr 24 16:28:42 CDT 2002

Reply inline:

 - Dave

Julian Fitzell wrote:
> 
> Dave wrote:
> > Julian Fitzell wrote:
> >>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.
> 
> <sigh> Fine. whatever.
</sigh>

> 
> >>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.
> 
> But *every client in the world* then needs to do this.
Every client that parses XML _should_ be doing this already.  Any client
that doesn't isn't really parsing XML properly :-(

>  There are tons 
> of clients out there just just print out the message body as if it is 
> text.  Yes, it's XML but people have used <body> as plain text and 
> that's what people expect it do be (at least in the IM case).  If you 
> stick any kind of XML tags inline those will get printed out verbatim by 
> thousands of clients all over the world until all their authors do 
> regexp (and not all languages have built-in regexp.
How about having a new <xmlbody> element that will contain a _real_
XML version of the message?
/me starts to contemplate the following:
<message to="fact_logger at dave.tj"><xmlbody>
 <fact><verb tense="present" name="think">
  <subject><noun person="1" number="singular" gender="m"/></subject>
  <object>
   <fact><verb tense="present" name="is"><adverb name="should"/>
    <subject><noun name="Jabber"/></subject>
    <object><noun name="XML"><adjective name="pure"/></noun></object>
   </verb></fact>
  </object>
 </verb></fact>
</xmlbody></message>

>  (And don't say 
> there are libraries because not all client authors are going to agree to 
> import a regexp library just to do this).
...and they'll agree to import regexp libraries just to do the plain-text
emoticon hack?  Something's wrong here. . .

> 
> >> 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.
> 
> Not necessarily images downloaded from a server.  Just because you can 
> display bitmaps (not windows bitmaps) that are stored directly in your 
> application *does not mean* you can display .png or .gif or .jpg or 
> whatever and it certainly doesn't mean you have http support.
Those clients will presumably use the ALT attributes of any images they
can't (or refuse to) get (just like regular Web browsers).

> 
> >>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) :-)
> 
> What if the person sending me porn doesn't play nice and send me 
> relative urls?  Even if they didn't am I going to have a local copy of 
> "xxx.jpg"??  guess I'll have to go download the remote version...
...unless you've set up your client not do download images, in which case
you'll get the ALT attribute instead ... which is probably a text-based
version of the emoticon :-)

> 
> >> 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 :-(
> 
> It's not the point.  Identify what the smiley is, not what you think the 
> filename for an image should be.
The filename of the image should be the name of the smiley.

> 
> 
> >> 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'd love more discussion on feature negotiation.
...not in this thread, since everybody will probably miss it in the
normal course of ignoring our thread :-(

> 
> 
> ARGHHH.  You're not listening to anything anybody is saying and you're 
> throwing answers back without thinking them through.
What did I not listen to?

> 
> I personally hate any system that involves the sender specifiying image 
> files for emoticons for reasons I specified point by point in my 
> original mail.
I believe I answered every single one of them.

> 
> If we want to come up with some unique entity that represents emoticons 
> so that we know that (0) isn't part of some code instead then great. 
Cool :-)

> Just make sure you consider all the clients that don't and/or won't 
> support this feature.
As of now, most clients support stuff in whatever crazy way the author of
each intended.  It's not like we're trying to switch from an established
standard to some brand new thing (well, maybe it is - but the advantages
are worth it, especially if we can maintain backward compatibility).

>  You can't go randomly throwing stuff inside the 
> <body> tag because many clients will not parse it
Point taken ... I hereby propose an <xmlbody> tag :-)

> (and you can't throw 
> the message text directly in the <message> tag as your examples were 
> suggesting).
I was too lazy to include the <body> tag in those examples (or I forgot
to - I don't remember anymore) ... quit nitpicking, please?

> 
> You've suggested about a dozen features that you claim are simple to 
> implement but require all clients to be rewritten, custom servers to be 
> developed, standard HTML browser components to be reverse-compiled and 
> modified, etc... I will never, ever, ever, implement this in any client 
> I write.
Wowowowow ... I don't seem to remember proposing the vast majority of
that. . .

> 
> Anyway, I suggested I was stepping out of this conversation before but I 
> am absolutely doing it now.  I am not posting any more comments in this 
> thread under any circumstances.  It's too long and pointless and its 
> illogic frustrates me every time I read it.
/me dances around, chanting "You can't talk now!  You can't talk now!"

> 
> But, no, I'm not removing my vote.  I'll let you know if you convince me 
> with a reasoned argument. :)
/me ponders the $64K question: How will you let me know if you can't talk???

> 
> 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
> 