Custom Clients

Earlier in this chapter we discussed features of 'off the shelf' clients such as WinJab and Jarl, clients that natively support the headline <message/> 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 client sjabber 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; [1] an extension to the Perl libraries for Jabber (Net::Jabber) to carry XML-RPC-encoded messages also exists. [2]

So, a Jabber client doesn't need to follow any particularly conventional model, except if you're developing an IM client, of course, and even then, flexibility and fitness for purpose is key. We will see this philosophy in action in Part II of the book, where we develop just enough Jabber client code to be able to connect to a server, authenticate, and deal with one-way alert-style messages. This is a key idea: you use as much, or as little, of what Jabber has to offer to build your solutions. This doesn't just refer to the Jabber building blocks, but also to the existing software, in particular the clients. For example, if you wanted to develop a Jabber IM-based approval cycle workflow process you could carry the approval data in a custom namespace-qualified message extension. In this case, you're going to have to build a custom client to interpret that extension. However, if you carry the approval data inside the body of a normal message then you can more or less take your pick of ready-made clients. Furthermore, if you include URLs in the message body —which many graphical clients can render into an active link— you can easily bind in the power of existing web-based interactivity to complete the solution.