Programming Jabber

Along Came Jabber

So Jeremie resolved to create a solution that had the following characteristics:

• It would have its own internal protocol, based upon XML.

• This protocol should be:

  • Simple to understand and implement

  • Easy to extend

  • Open

• The complexity of bridging the disparate proprietary IM protocols would remain at the server, each bridge being a plug-in module.

• All the clients would have to implement only the single, simple open protocol; everything else would be implemented at the server.

He called this solution “Jabber.”

The main architectural feature for Jabber that Jeremie strived for was that it should be simple enough for anyone to implement a Jabber server of his own. Unlike a centralized server environment, with all of the traffic routed through a central point, Jeremie envisioned that Jabber would be decentralized, allowing individuals, companies, and public organizations to run their own servers. This is particularly relevant for internal-only, IM-style corporate communications. Just as email servers are used to exchange mail using the Simple Mail Transport Protocol (SMTP), the Jabber servers are able to connect and exchange IM traffic whenever necessary. Figure P-1 illustrates Jabber’s distributed architecture, with two separate Jabber servers serving separate users.

Figure P-1. The distributed architecture of Jabber

Being open meant that Jabber could benefit ...