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
![http://somewhere/myenvelopeimage.png"](http://somewhere/myenvelopeimage.png"){kind=link}