[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[JDEV] [Transports 1.0]
I don't have all that much to put here right now, but I'd like this to
become a guide to writing transports.
A transport is really just an addressable namespace,
@transportname.server.com or if it's only available on one local server,
just @TRANSPORTNAME. Right now, the only types of information that is
routable is messages and status updates, so that is all a transport has to
deal with. And if it it's transporting to a system that doesn't reflect
"status", then it can ignore those.
The first thing that a transport will do is open a connection to the local
JabberBox. If it has a section in the main config file loaded by the
JabberBox, it will then receive that config data and initialize itself.
After it knows what names it will be addressed as, it should feed those
names/aliases back to the JabberBox so that it can start receiving/sending
data.
>From that point forward, it's quite simple. It will receive
messages/status updates sent to it over the socket with the JabberBox,
from which it can parse out and deliver to whatever system it's
translating to. All messages/status updates sent out through the socket
with the JabberBox should be delivered normally or bounced back.
Now, some of the issues a Transport will have to deal with, is how to
handle user accounts for the systems it's translating to and how to
associate Jabber users with their IDs on the other system.
We should probably agree on a set of special address that every transport
is required to respond to, maybe:
register@ Allows interactive registration via messages
help@ Give assistance, possibly w/ URL's
info@ Talks about this transport, what it does
url@ Just sends back a URL for a page with more information
Let's use ICQ as an example...
First, an association needs to happen between a Jabber user(John) and a
user account on ICQ. Let's say that John is already an ICQ user, so he
has an ID# and a password. He would send a message to register@ICQ and
configure it to use #123456 and his password. If it looks/works ok, the
ICQ transport would then send a roster list invite("Please add me to your
roster...") to John, and John would have 123456@ICQ on his roster.
Whenever John logs in, the ICQ transport would receive that status update,
and then log into ICQ for John and translate all messages/status updates
between both systems.
If John never had an ICQ #, the ICQ transport should be able to create one
on the fly for him, either by asking for the needed information or by
querying the public Jabber information available for John.