[JDEV] User existence in Jabber Server

[Dave]

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" <dave at dave.tj>
> To: <jdev at jabber.org>
> 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" <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
> > >
> >
> > _______________________________________________
> > 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
>