[JDEV] Jabber Transports - New Architecture

James Widman j-widman at cornellcollege.edu
Fri Mar 8 01:08:28 CST 2002


/me nods to the three previous replies.

The concept of null clients also gets raised during conversations like 
this.  That's a nice idea too, but not really necessary.

This is all you have to do:  

1) If jabberd and the transports you want aren't known to work on your 
platform, port them.
2) Configure jabberd so that the server's host name is localhost, and 
transports are running at aim.localhost, msn.localhost, etc.
(I tested this part out and it works for me; contrary to the *current* 
server howto, you don't need a Fully Qualified Domain Name to get 
transport services like aim-t and msn-t working; you just need the 
client to be on the same machine as the server if it's not an FQDN).
3) Use your client to log into localhost and register with the 
transports from there.  
   
    The drawback here is that you at localhost cannot send messages to 
me at jabber.org.   However, one feature that's been requested for clients 
is the ability to be logged into multiple jabber accounts 
simultaneously.   As time goes on, this will probably become a pretty 
common feature, especially as jabber becomes more popular and more 
people request it (actually, if it's ok with Julian, and if enough 
people email me in support of it, I'd be happy to work this into 
Gabber).  If and when it becomes a common feature, it could make a lot 
of sense to put together a jabberd package which is optimized for use by 
a small number of users and comes with the most popular inter-IM system 
transports.  Would that help to ease the transition for end users?

   There's only one problem I can spot with a configuration like this: 
 the roster info for the localhost account will not follow you around 
from one device to another.  The user would have to manually do an 
export/import.  But there might be a clean way around this (if we're 
going to have multiple accounts managed by one client, we might want a 
clean way to store roster info on what the user designates as a 
"primary" account anyway -- but *please* correct me if I'm wrong).

--James




More information about the JDev mailing list