Programming Jabber

IM System Features

This book assumes you have a basic knowledge of features commonly found in IM systems. In case you don’t, here’s a brief rundown of features relevant to what we’ll be covering:

Presence

In many cases, there’s not much point in sending a quick message to someone if they’re not there. Presence is a term used in IM to describe the technique of exchanging information, in a controlled manner, about availability (or unavailability).

The idea is that when you connect to your IM server, your client sends an “I’m here” message that is relayed to your correspondents. It does the opposite when you disconnect. During the time you’re connected, you can vary the information about your availability to reflect your immediate situation (“just popped out for coffee,” “working on my resumé—don’t disturb me!”).

Buddy List™/roster

Both terms (the former comes from the original IM systems, the latter from Jabber) refer to a list of correspondents with whom you regularly communicate and from whom you receive presence information. Depending on the IM system, the list may be stored on the client or on the server. Storing the list on the client has the (tenuous) advantage of being accessible when you’re not connected to the server. Storing the list on the server means that you have a consistent roster content regardless of the client or workstation you happen to use—the list travels with you.

Jabber stores the roster on the server.

Push and pull

When you connect to an IM system, there may be information the client needs to retrieve—pull—from the server (the roster, for instance). This is under direct control of your client as it decides when to make the retrieval. During the course of the connection, you’ll receive messages from your correspondents. You don’t request these messages by making a retrieve call to the server, as you would with the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) to retrieve email messages from the mail server; they’re pushed to you as they occur.

In other words, you could say that the client must implement an event-based system, to listen out for and subsequently handle the incoming information, by displaying a pop-up window containing the chat message, for example.

The push/pull system lends itself well to traffic other than IM traffic.

Client-server

It almost goes without saying that, like other IM systems, Jabber has a client-server architecture. Clients and client libraries that implement the Jabber protocol, such as Net::Jabber, Jabber::Connection, Jabberpy, and JabberBeans, are available for many languages (here, for Perl, Python, and Java).

With Jabber, it is especially relevant to stress that the “weight balance” in complexity terms, between the client and the server, comes down heavily on the server side. Not only does this mean that the complexity remains where it should be—on the server—but also makes the task of writing clients easier and the resulting software lighter.

Multiple versus single server

We’ve already mentioned that the Jabber architecture does not dictate a single, centralized server. Not only does this mean that organizations can implement their own private system, but also that developers are free to install their own server and develop new plug-in services in addition to the IM bridges already available.