Groupchat, : Components, and Event Models

By now, you should have a

good idea of how scripts interact with Jabber and how the core

elements such as <message/> and

<presence/> can be constructed and handled.

This chapter builds upon what we've already seen in Chapter 8 and
introduces new concepts. We build a nosy assistant that joins a
conference room and alerts us to words and phrases that we want it to
listen for. There are two popular conference protocols, as mentioned in
Section 6.2.6 the presence-based Groupchat protocol, and the
jabber:iq:conference-based Conference protocol. The assistant
recipe, a foray into the world of 'bots, takes a look at the original
presence-based one.

As we've seen, programming within Jabber's event model is fairly
straightforward. But what happens when you want to meld other components
with event models of their own? We look at a couple of typical scenarios
where this melding needs to happen. The first is a homage to the Trojan
Room Coffee Machine (http://www.cl.cam.ac.uk/coffee/coffee.html), where
we give life, or at least presence, to a coffeepot, using LEGO
MINDSTORMS. The second is a Tk-based RSS headline viewer. Both the
coffeepot and the Tk programming library have event loops of their own.
With the coffeepot, we need to have a loop that polls the coffeepot's
status, independently of the polling for incoming packets from the
Jabber server. The Tk programming library's event model is similar to
those of the Jabber programming libraries that are used in the recipes
in this book, in that handlers are set up and a loop is started that
listens for UI events. In both cases, we need to get these event loops
to work in harmony with the Jabber libraries' event loops.

Building Jabber solutions without event loops is a Sisyphean task. The
very nature of Jabber communication is event-based, and it's important
to understand how to use the event features of the Jabber programming
libraries and also how to be able to mesh those features with similar
features in other libraries and systems.

We also look at extending messages and build a mechanism that delivers
RSS headlines to clients who register with that mechanism. These
headlines are carried using an extended message type. In fact, the RSS
Delivery Mechanism is a component. The three recipes in Chapter 8,
were Jabber clients, in that they connected to the Jabber network
via the Jabber Session Manager (JSM) service. We look at the differences
between programming a client and programming a component in this chapter
and build a complete component that can be queried and interacted with
using the third of Jabber's building blocks the <iq/>
element.

Happy coding!

Keyword Assistant

Many of the Jabber core and peripheral
developers hang out in a conference room called jdev hosted by the
Conferencing component on the Jabber server running at jabber.org.
While a lot of useful information is to be gleaned from listening to
what goes on in jdev, it isn't possible to be there all the time.
Conversations in jdev are logged to web pages, which can be used to
visit after the fact to try to catch up with things; however, this can
be a hopeless task. One solution is to build a 'bot that looks for
specific keywords and Uniform Resource Locators (URLs) in the
conversations in jdev and send those on as Jabber messages.

This script, keyassist, connects to a Jabber server, enters a
conference room, and listens to the conversations, looking for certain
words and phrases to be uttered. The keyassist script is given a bit
of "intelligence" in that it can be interacted with and told, while
running, to watch for (or stop watching for), certain words and phrases.

The keyassist script introduces us to programmatic interaction with
the Conferencing component. Before looking at the script, however, let's
have a brief overview of Conferencing in general.

Conferencing

The Conferencing component at jabber.org is
conference.jabber.org. Details of the component instance
configuration for such a Conferencing component can be found in Section
4.10, where we see that the component exists as a shared object library
connected with the library load component connection method. This
component provides general conferencing facilities, oriented around a
conference room and conference user model.

A Jabber user can enter (or join) a conference room, thereby
becoming a conference user identified by a nickname that is chosen upon
entering that room. Nicknames are generally used in conference rooms to
provide a modicum of privacy it is assumed that by default you don't
want to let the other conference room members know your real JID.

The Conferencing component supports two protocols for user and room
interaction: a simple one that provides basic features and a more
complex one that provides the basic features plus facilities such as
password-protected rooms and room descriptions Groupchat and Conference.

{{Note|There is a third protocol, called
Experimentaliq:groupchat, which came between the Groupchat
and Conference protocols. This reflected an experimental move to add
features to the basic Groupchat protocol using IQ elements, the contents
of which were qualified by a namespace jabber:iq:groupchat.
This protocol has been dropped, and support for it exists only in
certain versions of WinJab and JIM.

</code>

Groupchat

The Groupchat protocol is the simpler of the two and provides basic

functions for entering and exiting conference rooms and choosing

nicknames. : This Groupchat protocol is known as the presence-based

protocol, because the protocol is based upon

<presence/> elements used for room entry, exit, and

nickname determination. The Groupchat protocol has a nominal version

number of 1.0.

Conference

The Conference protocol offers more advanced features than the

Groupchat protocol and makes use of two IQ namespaces:

jabber:iq:conference and jabber:iq:browse. It has a

nominal protocol version number of 1.4, which reflects the version of

the Jabber server with which it is delivered. Sometimes this version

number is referred to as 0.4, such as in the downloadable tarball and

in the value returned in response to a "version query" on the

component itself, as shown in Example 9-1. : The version number isn't

that important. The main thing to keep in mind is that the component

that is called conference.so (see the reference to the

shared object library in Section 4.10.4) supports both the

Groupchat protocol and the Conference protocol. If you come across a

shared object library called groupchat.so, this is the

original Conferencing component that was made available with Jabber

server Version 1.0. This library supports only the Groupchat protocol.

RECV: <iq to='dj@gnu.mine.nu/jarl' from='conference.gnu.mine.nu'
type='result'> <query xmlns='jabber:iq:version'>
<name>conference</name> <version>0.4</version>
<os>Linux 2.4.2-2</os> </query> </iq>
In this recipe we'll be using the simpler Groupchat protocol. It's
widely used and easy to understand. Example 9-2 shows a typical element
log from Groupchat-based activity. It shows a user, with the JID
qmacro@jabber.com, entering a room called "cellar," hosted on
the conference component at conf.merlix.dyndns.org, a room that
currently has two other occupants who go by the nicknames
flash and roscoe. The elements are from
qmacro's perspective, and are all explained following the
example.

The Groupchat protocol in action The user qmacro tries to
enter the conference room with the nickname flash and fails: