----- Original Message ----- From: "Dave" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
![http://somewhere/myenvelopeimage.png"](http://somewhere/myenvelopeimage.png"){kind=link}