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

Re: [JDEV] [Transports 1.0]




I really like the idea of these transports, especially the ICQ one. I'm
not sure how much (if any) progress is being made, but I'd like to
volunteer my efforts.. 

The project seems a little hectic, at least until there is a good CVS tree
setup.

Nicholas Kirsch
nkirsch@biznatch.nick.org

On Wed, 3 Feb 1999, Jeremie wrote:

> 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. 
> 
>