[JDEV] [JabberBox 1.0]

[Jeremie <jeremie@jabber.org>]

#### Intro

The JabberBox is simply a "data router".  It resolves the transport/server
names and routes chunks of XML between them, creating sockets where
needed. 

When the JabberBox starts, it reads in the main configuration file for
itself and all of the local transports.  It then starts two listening
sockets, one on localhost:5269 and the localnetaddress:5269. 

Connections to the localhost:5269 are most likely from transports.  When a
transport connects it has the special permission to receive its chunk of
the main configuration file.  After it initializes, it provides the
names/aliases it is to be known as. 

#### Protocol

The transport might send:
	<?xml version="1.0"?>
	<jabberbox name="TPNAME">
Then the server would respond:
	<?xml version="1.0"?>
	<jabberbox>
	<config>--this is raw data from the main config file for TPNAME</config>
Then the transport would initialize and send:
	<alias>TPNAME</alias>
	<alias>tp.server.com</alias>
At this point the JabberBox is ready to start delivering incoming data to
the transport and the transport is configured and ready to receive.  What
the transport would send/receive would look like: 
	<r from="tp.server.com" to="other.server.com">--raw XML data</r>

Connections from other servers come in on the local Internet socket on
port 5269, and are only allowed to send data and receive errors/bounces.
Any data destined for another server is delivered through a new socket to
that server, and that socket remains open until there is an internal idle
timeout or the JabberBox exits. 

A typical connection from another server and chunk of data might look like:
	<?xml version="1.0"?>
	<jabberbox name="other.server.com">
	<r from="tp.server.com" to="other.server.com">--raw XML data</r>
	</jabberbox>

The JabberBox resolves the "to" sides of these <r></r> "packets" and
delivers them, otherwise it bounces them with another packet: 
	<r to="tp.server.com" from="other.server.com" error="noname">--raw XML data</r>
The error will then be delivered back to the original sender server/transport.

Essentially, the JabberBox is just a server routing XML documents in
chunks to other JabberBox's or local transports.  It doesn't touch the
contents of the <r></r> packets.  Since it's the main server process, it
also provides an easy way to centrally manage the configuration data for
local transports. 


#### Ideas

What I would like to see, is some slight additions made to the protocol
between a transport and the JabberBox, so that transports can feed the
JabberBox two types of administrative information.  When they connect,
they could optionally send a public info packet, stating whether they
allow public registrations, what type of transport they are, if they have
a web site, number of registered users, a whole host of one shot
information.  Also, periodically, they could send in temp stats such as
number of connected users, number of users logged in so far today, etc...
The local JabberBox could then send all of this collected data upon
request, mostly for the local administrator or as cool statistics for the
website for this Jabber installation. 

The next step would be to have the JabberBox send in this information to a
central Jabber server(@jabber.org) and global stats can be kept as well as
a current list of online servers that anyone can register with and
information about them.  For an example of something similar, check out
http://www.shoutcast.com/

Another idea that would fit in with the JabberBox, is for users that are
running a server and multiple transports, and don't have the ability to
easily add DNS aliases to make those transports publicly addressable.  A
possibility would be to build a DB driven DNS server and do the ml.org
thing but IP registrations would be done through Jabber, but hopefully
someone will step up to the plate and do this before we have to :) 
Another easier possibility would be to allow the JabberBox to send in an
automated registration request to a special JabberBox server running
possibly @jabber.org.  This special server would take those registrations
as if they were real transports and route data to those servers.  Then
this special JabberBox could have a wildcard DNS address like
*.home.jabber.org or *.public.jabber.org, and the registration request
would contain what name they wanted like scoobydoo.public.jabber.org. 
Other than bandwidth, this is definitely an option that would work and be
fairly easy to implement.