Programming Jabber

Asynchronous Nature

The exchange and distribution of information in real-world scenarios requires more than a synchronous (sequenced) request/response framework. In IM, people originate chat messages in a spontaneous and unpredictable manner (especially if there’s beer involved). In a loose network of independent applications, messages originate on a similar “random” event basis. This asynchronous activity requires a design equally asynchronous in nature—and that is what Jabber has.

To allow for the generation, and more importantly the receipt, of messages in an asynchronous fashion, Jabber’s programming model for client and server alike is an event-based one. An event-based programming model is nothing to be afraid of. In simple terms, it’s just a loop that iterates either doing nothing in particular or doing something regularly (like checking for user input and acting upon it if required) while waiting for something (an event) to happen. In Jabber’s case, it will be the receipt of an XML fragment. Depending on what type of fragment it is, a handler will be called to deal with that fragment. We saw a simple example of this in the Perl script in Chapter 1.

In all but the simplest deployment examples of Jabber, the event model pervades. We will see the model in action in Part II. And while we’ve reduced the receipt of chat messages to a rather dry and generic event idea, let’s also look at some concepts that often go hand in hand with event-based messaging systems.