Programming Jabber

Custom Clients

Earlier in this chapter, we discussed features of off-the-shelf clients such as WinJab and Jarl, clients that natively support the <message type='headline'/> element. Considering this, in combination with the features we know Jabber posesses and the solution potential that these features offer in presenting a wider deployment vista than IM services, we come to an interesting conclusion:

A Jabber client is a piece of software that implements as much of the Jabber protocol as required to get the job done.

What does this mean? WinJab supports a Jabber feature called browsing (see later in this chapter); Jarl supports connections to the server via an HTTP proxy. Some clients merely support a limited subset of Jabber as we know it; for example, the sjabber client supports only the conferencing features of Jabber. (As a somewhat biased observer, I would, of course, call this “extremely focused.”)

Our definition of a Jabber client deliberately omits any mention of a user interface (let alone a GUI!). Indeed, human interaction in a Jabber solution is only an assumption formed from the hangover of the IM idea. Various efforts are underway to use Jabber as a transport for A2A messaging—the Jabber As Middleware (JAM) project is one such effort (at http://mailman.jabber.org/listinfo/jamdev); an extension to one of the Perl libraries for Jabber (Jabber::Connection) to carry XML-RPC-encoded messages also exists (http://www.pipetree.com/jabber/jrpc/), which is shown in