[JDEV] Emoticons: guidelines

Wed Apr 24 03:07:42 CDT 2002

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.

>>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.  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.  (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).

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

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

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

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

ARGHHH.  You're not listening to anything anybody is saying and you're 
throwing answers back without thinking them through.

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.

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. 
Just make sure you consider all the clients that don't and/or won't 
support this feature.  You can't go randomly throwing stuff inside the 
<body> tag because many clients will not parse it (and you can't throw 
the message text directly in the <message> tag as your examples were 
suggesting).

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.

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.

But, no, I'm not removing my vote.  I'll let you know if you convince me 
with a reasoned argument. :)

Julian

-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)