[JDEV] Emoticons: guidelines

[Dave]

I must be seeing double :-(

 - Dave


Richard Dobson wrote:
> 
> 
> ----- Original Message -----
> From: "Dave" <dave at dave.tj>
> To: <jdev at jabber.org>
> Sent: Monday, April 22, 2002 2:17 PM
> Subject: Re: [JDEV] Emoticons: guidelines
> 
> 
> > Reply inline:
> >
> >  - Dave
> >
> > People who are behind firewalls and proxies can upload their favorite
> > emoticons to GeoCities, and have their clients put in references to
> > there automatically.
> 
> And you expect normal people to this ?? (normal people as in
> non-programmers/web devs, people like new computer users, new people to the
> internet who just want to chat to their friends)
> It also requires that people have their own webspace if they want to use
> emoticons.
> And if you mean a client should auto-upload them, then that is completely
> unnecessary complexity for something simple like emoticons.
> All that needs to be done is standardise a standard set of emoticon codes so
> each client will know what emoticon should be used.
> 
> >
> > > And what about the unneccessary bandwidth it takes up, not just in the
> xml
> > > but having to download those images,
> > Well, if you _really_ want to use whatever emoticon the recipient
> > already has (presumably, from his own Jabber client installation),
> > you can just use src="envelope.png" src="mail.png" along with any other
> > likely names the graphic is likely to have, and maybe include a default
> 
> Using the filename to try and tell what emoticon is being used is completely
> unworkable, and I dont think I have to explain why, but if anyone requires a
> clarification feel free to email me.
> 
> > src="http://somewhere/myenvelopeimage.png" attribute, in case the guy's
> > client doesn't have any such icon.  This still prevents the formation of
> > a "standard" set of emoticons for Jabber, that all clients must support,
> 
> Why does it stop the formation of a standard set of emoticons ?? As long as
> the icons that are being used represent what they are supposed to. All we
> are trying to standardise here is a way for each client to know what each
> emoticon code means not a single standard set of emoticon graphics.
> 
> > and whose interpretation (and therefore the implementation of the icons
> > by different clients) is guaranteed to lack uniformity.  It also means
> > that every time we add "standard" emoticons, clients without support
> > for that particular emoticon will be left in the cold.  We can always
> > have a "reference set" of emoticons at http://img.jabber.org/emoticons/
> > and have clients make hyperlinks referenced there by default, but we're
> > maintaining the capability for anybody to send any emoticon he may want
> > to send, without being limited by the "emoticon approval process" that's
> > going to develop if we try to standardize emoticons directly.
> 
> Yep there can always be a reference set of emoticon graphics for client
> dev's to start from or use.
> 
> >
> > > for something like emoticons isnt it
> > > better just to have a way of defining that something is an emoticon and
> what
> > > it represents so particular clients can display emoticons that better go
> > > with a particular clients graphical style,
> > I demonstrated above that this isn't a concern if we use an HTML IMG tag
> > (since if the sender wants you to use your default emoticon for something
> > - i.e., it's not important that you see the exact same emoticon that
> > he sees when he composes the message - he can list a local (assumed to
> > originate on your machine) URL before the URL of his emoticon).
> 
> But again using filenames is unworkable, filenames of emoticons will
> unlikely be always the same.
> 
> >
> > > and also whats to stop abuse of
> > > this by either embedding enormous images that take ages to download or
> an
> > > image with silly dimensions,
> > Karma stops many bad things in the Jabber world :-)
> > ....and the silly dimensions problem can be solved client-side by anybody
> > who wishes to restrict the dimensions of incoming images.  I see no
> > reason to use an infrerior solution simply because the more general
> > solution requires a bit of protection on the part of the receiver.
> 
> Im sorry but I think embedding a massive bit of HTML code into the message
> everytime an emoticon is encountered is the inferior solution, that should
> be restricted to the reason previously stated as it dramatically increases
> the size of the xml.
> 
> >
> > > also i will cause problems where people use a
> > > lots of emoticons within a message,
> > Yes, I'm sure you will cause a lot of problems, sending too many emoticons
> > within a message ;-P
> 
> it will cause problems, you know what i meant.
> 
> > However, naming "standard" emoticons doesn't lessen the load on the
> > receiver's client's rendering engine - or even on his 'net connection,
> > if he doesn't store emoticons locally.  (Even a client that _does_ store
> > some emoticons locally is likely to reference another repository out
> > on the 'net, unless it decides to include some method for updating its
> > local repository whenever new emoticons are "standardized" ... or unless
> > the client developer decides to use update.jabber.org to broadcast
> > a "new" version of his client every time a new emoticon is added.
> > As you can probably guess, the situation has the capability of getting
> > rather silly.  I'd strongly suggest not trying to standardize within
> 
> Why does it have the capability of getting silly, and why cant a client have
> update functionality that can include updating its emoticons as well as the
> rest of its components ??
> Also when did I ever suggest that naming standard emoticons lessens the load
> on the receiver clients rendering engine??
> All I said was that it unecessarily takes up bandwidth.
> 
> > Jabber something which isn't even a standard outside of Jabber: let
> > people go with whatever conventions they like, and the world will be a
> > much better place.  If the ISO ever decides to standardize emoticons,
> > I'll be the first to recommend using the standard in Jabber.)
> 
> Setting standards and protocols is what allows everything to communicate,
> whats wrong with standards ??
> 
> > > something like emoticons i dont think is
> > > best delt with by embedding it in this way.
> > Obviously, I'd tend to disagree ;-)
> 
> Of course you would, it doesnt mean you are right, emoticons are a client
> feature and should have the ability to be turned off, which in your method
> they cant be without turning off all embedded images, also there is no way
> of stopping the sending person from sending them in the xml in the first
> place, which especially in your method consumes excessive amounts of
> unnecessary bandwidth which on things such as GPRS devices is a very
> expensive thing, and for such devices you want to use the least amount of
> bandwidth possible, also those sort of devices can currently display .png or
> .gif, only .wbmp, should these be not allowed to use emoticons? No everyone
> should be able to. Also what about the MSN transport, to allow emoticon
> compatibility using your method would put much more load onto the msn
> transport than necessary.
> 
> >
> > >
> > > This is another good enhancement but I think is better for embedding
> images
> > > that are only going to be sent spairingly, like someone sending a
> picture of
> > > their cat or something inline in the im client, like the AIM image
> sending
> > > feature.
> 
> > Well, if we're going to need this _even if we use "standadized"
> > emoticons_, we'll be opening this "can of worms," as you put it, anyway.
> > We might as well avoid having the "standardized" emoticon system
> > altogether, since it's strictly a slightly incompatible subset of the
> > HTML IMG tag approach.
> 
> I never said "can of worms" at all anywhere so I didnt put it like that.
> Its not a slightly incompatible subset of the HTML IMG tag at all, your
> particular suggestion has that solution but I dont think that by any means
> it is the best solution, it introduces many more problems than any other
> solutions.
> 
> >
> > >
> > >
> > > Rich
> > Dave
> >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>