Extending the Jabber Architecture

This document will explain where to build on the Jabber architecture based on your needs.

WORK IN PROGRESS

By now you should have read the general overview and understand the various different components, clients, transports, etherx, etc. You should also have in mind what your needs are, and what functionality you would like to have in the end. There are many different modular pieces to Jabber and figuring out exactly which one you want to extend may not be a trivial task. Some needs can be solved multiple ways, and choosing the appropriate one is important.

Lets talk a little about each area and list the typical project that would fit well in it:

Clients

This is the most obvious area. If you simply want to allow users of your software to communicate with Jabber users, and haven't done any development yet, writing a client is probably what you want to do. Clients are the layer between the end user and the Jabber server, encoding and sending data in XML over a socket to the server, understanding what the server sends in return and displaying it to the user.

There is a special type of client called the multi-client, which allows one connection to the server to become a channel for multiple users. This is useful if you are building a web-based gateway for users using a browser, building a proxy, or for other special purpose applications. A more peculiar example would be a pager gateway, where it could connect and show up as a session for a group of users using a paging service, translating between the paging service and other Jabber users.

It's easy to accidentally abuse the client end of things with special purpose applications, so here is an important rule of thumb: Clients are ONLY for USER sessions, meaning that client software should only be used when there is an actual individual receiving messages and there is the possibility for a "session" where interactive communications happen between this user and other users. Notable exceptions are automated error/reporting tools that might deliver errors via Jabber, they would just connect as a client, send the message, and disconnect.

If you are unsure yet wether you want to build a client for your purpose, then read on below and you may find a better way. Here are some examples of possible projects around the Client approach:

Modules

Modules are very special purpose, and utilized only on the Jabber server. They allow developers to extend almost any aspect of the server and to add rich layers of functionality in a modular and configurable way. A module has the ability to manage almost any aspect of a Jabber user account, from authentication to message delivery, roster management, and logging. If you want to add features to Jabber itself, you might want to develop a module.

Transports

Transports are a critical piece of Jabber. They are the processes that "translate" from Jabber to other systems, such as ICQ, AIM, Yahoo Pager, and so forth. If you would like to add transparent connectivity for any Jabber user to another real-time messaging service, use a transport. This includes adding any additional protocol functionality such as RVP, IMPP, or otherwise. Also, this is the right place to add any real-time "information source", such as stock quotes, weather alerts, etc.

Another significant possibility with transports is if you have a real-time service already with clients, and want to provide the features of Jabber to those clients. By connecting your server to the Jabber network as a transport, all of your client immediately can communicate with the rest of Jabber as well as utilize any of the other transports. This is an excellent approach if you want to write a 100% secure real-time messaging network and still provide connectivity with other services.


These documents are a work in progress. Please direct any questions to team@jabber.org.