Programming Jabber

Host Filter

Assuming that our hostname isn’t sessions, it’s just as well that we have a <host/> specification in this component instance description:

<host><jabberd:cmdline flag="h">yak</jabberd:cmdline></host>

which means that this Session Management component instance will handle packets addressed to the host yak.^[2]

The <jabberd:cmdline flag="h"> ... </jabberd:cmdline> wrapper around the hostname means that this value (yak) can be overridden by specifying a switch -h (hostname) when jabberd is invoked, as is described in Chapter 3. If you’re sure you’ll never want to override the hostname setting here, this <jabberd:cmdline/> wrapper can safely be removed from the configuration, to leave:

<host>yak</host>

As described earlier, you can specify more than one hostname; use a <host>...</host> pair for each one. This will effectively give you a virtual server effect where Jabber will respond to different hostnames. This is useful in situations such as deployment in an ISP where a single host serves multiple domains. The client data stored on the server (such as rosters, offline messages, and so on) is stored by the xdb component by hostname, so that a separate directory in the spool area will be used for each specified hostname.

For example, if you specified the two hosts:

<host>a-domain.com</host>
<host>b-domain.com</host>

then the data for two users [e-mail] and [e-mail] would be stored as shown in Figure 4-6.

Figure 4-6. Storage of server-side user data ...