[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[JDEV] Client nicks
Well, I was perusing the client/server protocol, looking at this
<j type='roster'>
<group name='main'>jenny</group>
<group name='friends'>user@jabber.server.com</group>
<group name='main'>545212@ICQ</group>
<group name='system'>olduser</group>
</j>
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.
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? Only way I see, is
for the client user to tell the client that this is an incarnation
of a particular Jabber buddy. This would require the client to
actually save the roster, which is anti-jabberlike.
I would have suggested that the server also store arbitrary bits
of information for the client, but havoc would be wrought if you
ran Windows client #1 at work, then Linux client #3 at home, and
they wouldn't understand the continually diverging extra "features"
coded into the other.
So, at the risk of severely annoying people who like certain
portions of the protocol, I'd like to suggest an alternative.
- Jabber client creates a user account on a server, with a
main username that becomes the default nick:
bubba@jabber.server.org
- Client then adds nicks to the account, each having the
following information:
name to display
default priority
transport to be used (jabber, icq, aim, smtp, etc.)
transport id (if not Jabber; ICQ UIN for example)
When Bubba creates an ICQ nick, the ICQ transport is instructed
to add this number to its list. When ICQ's server indicates that
he's logged on, the ICQ transport sends a status message about
that nick/user to the server, which tells its Jabber transports
to send a status message to everyone that has Bubba in their
buddy list.
In this way, the clients don't need to know what transport
is used for a particular nick. You don't need to give the
SMTP transport any special treatment, either. The SMTP
transport ought to report a low, online status at all times,
which could qualify it as the delivery point of last resort,
if and when that sort of thing gets hashed out. People who
don't want to receive email from Jabber could just omit the
SMTP nick.
I don't even think that implementing this would cause any
of the examples on http://jabber.org/developers/protocol.jab
to be changed. Once you've told the server what a nick
means, from then on you just specify the user and nick.
Adding an ICQ user to your list, when they don't use Jabber,
looks like it should remain the same. I suppose it wouldn't
hurt server developers too much to decide that any address
not including a period should be matched to one of the
plugged-in transports...
Joshua Swink
jswink@softcom.net