[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [JDEV] Client nicks





> Well, I was perusing the client/server protocol, looking at this
>  [proto example zappd]
> The address 545212@ICQ sticks out a bit.  In user@jabber.server.com,
> the second part of the address is the internet address of a server,
> while in 545212@ICQ it's the name of a particular type of service
> or transport.  I think this is a bad thing.

It's not, trust me :)

> Looking at Eliot Landrum's screenshots, you see a buddy's various
> nicks all grouped together, which is a good thing.  But the way
> the protocol's looking now, it seems like the client will only be
> able to do this automatically for actual Jabber nicks.  How can
> you associate 545212@ICQ with a Jabber user?

I think this is a common mis-conception that is causing more than a few
people some grief when trying to understand Jabber... I'll try to explain.

The id 23456723@ICQ is NOT a Jabber user, they are an ICQ user, so you
have an ICQ user on your roster.  ICQ users are not allowed to have
multiple logins on one account with different nicknames, so you will
*never* see sub-logins for this ID.

Correct me if I'm wrong, but I think the other mis-conception here is that
you will be able to use other clients to log into Jabber, like ICQ or AIM.
And although that is technologically possible if you write an ICQ "server"
that connects to Jabber on the backend(a challenge I would think), it is
not nor ever was the intention of what has brought Jabber to this point.
Jabber is a way for you to use a Jabber client and talk transparently to
users of Jabber or any other service(ICQ, AIM, etc) and for them to reply
to you.  So, as a Jabber user, you will be using Jabber clients and
logging into a Jabber server :-)

If that doesn't answer the other questions you had, let me know :)

BUT, after re-reading your message, I might be confused(it's late, that
happens all too often).  You might be suggesting that the actual ID's are
hidden from users eyes and nicknames are used instead... that might work, 
but it seems like it's something a client could do w/o the server...
hmmm... OK, lets go with this for a second.  Say a user has a roster in
their client up in front of them, and they have a few Jabber users with
multiple sessions, and an ICQ user or two.  Yes, the ICQ addresses are
ugly and unidentifiable, and my early thoughts on this issue were that the
ICQ transport would send along the ICQ user's "nickname" in the message
nickname field whenever a message was sent, and the client would use the
last recieved nickname(or a user's local override) to "cover up" the ugly
ICQ address.  This way the server doesn't have to do anything, and if the
client doesn't do that little "nicety" everything would still work and
simple clients wouldn't be expected to handle anything special or increas
the protocol in any way... make sense?

Hopefully somewhere in there I answered what you were asking/proposing,
*grin*

Jer