What does this have to do with my message (quoted by you below)??? - Dave
r-a-v-i wrote: > > Hi > If i want to know , while adding a user to my roster, whether the > same user exists in the Jabber Server or not, how should I do ?? > > Thanks in advance > > regds > r-a-v-i > > ----- Original Message ----- > From: "Dave" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 23, 2002 3:58 AM > Subject: Re: [JDEV] Emoticons: guidelines > > > > I must be seeing double :-( > > > > - Dave > > > > > > Richard Dobson wrote: > > > > > > > > > ----- 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 > > > > > > > _______________________________________________ > > 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
