Programming Jabber

Managing the Configuration

Now that we’ve had a tour of the components and have an idea what sorts of configurations are possible, you may be wondering whether there’s a way to retain some sort of overview of the actual XML. Dropping component instance definitions in and out of the configuration file is somewhat tedious, and certainly when editing such a large file, it’s not difficult to lose sense of direction and comment out or edit the wrong section.

Help is at hand, in the form of the <jabberd:include/> tag. This tag comes from the same stable as <jabberd:cmdline/> and provides the Jabber server administrator with ways to better manage the XML configuration.

The contents of a file specified with the <jabberd:include/> tag are imported (included) in the position that the <jabberd:include/> tag occupies. Depending on what the root tag in the file to be included is, the import is done in one of two ways:

• If the root tag matches the parent tag of <jabberd:include/>, the contents of the file minus the root tag are included.

• If the root tag does not match the parent tag of <jabberd:include/>, then the entire contents of the file are included.

For example, if we have a section like this in the jabber.xml file:

...
<conference xmlns="jabber:config:conference">
  <public/>
  <vCard>
    <FN>yak Chatrooms</FN>
    <DESC>This is a public chatroom service.</DESC>
    <URL>http://yak/chat</URL>
  </vCard>
  ...
  <jabberd:include>./rooms.xml</jabberd:include>
</conference>
...

and the content of ./rooms.xml looks like this:

<room jid="[e-mail]">
  <name>The Kitchen</name>
  <notice>
    <join> comes to add to the broth-spoiling</join>
    <leave> can't stand the heat</leave>
    <rename> is now known as </rename>
  </notice>
</room>
<room jid="[e-mail]">
  <name>The Cellar</name>
  <secret>cellarsecret</secret>
</room>

then these rooms will be defined to the Conferencing component as if the configuration XML had appeared directly inside of the <conference/> configuration wrapper tag.

We can put the <jabberd:include/> tag to good use and organize our configuration component instances as shown in Example 4-24.

Example 4-24. Configuration XML organized with <jabberd:include/>

<jabber>

  <!-- Core components -->

  <jabberd:include>./sessions.xml</jabberd:include>
  <jabberd:include>./config/standard/xdb.xml</jabberd:include>
  <jabberd:include>./config/standard/c2s.xml</jabberd:include>

  <!-- Testing -->

  <!--
  <jabberd:include>./config/local/conference.xml</jabberd:include>
  <jabberd:include>./config/test/test.service.xml</jabberd:include>
  -->

  <!-- Logging -->

  <jabberd:include>./config/standard/elogger.xml</jabberd:include>
  <jabberd:include>./config/standard/rlogger.xml</jabberd:include>

  <!--
  Internal-only server right now

  <jabberd:include>./config/standard/dnsrv.xml</jabberd:include>
  <jabberd:include>./config/standard/s2s.xml</jabberd:include>
  -->

  <!-- Misc -->

  <jabberd:include>./config/standard/jud.xml</jabberd:include>

  <!-- IO (incl. karma), PIDfile -->

  <jabberd:include>./config/standard/io.xml</jabberd:include>
  <jabberd:include>./config/standard/pidfile.xml</jabberd:include>

</jabber>

The XML in Example 4-24 gives us a great overview of which components are included in our Jabber server; we have the core components providing the Session Management, Client (to Server) Connections, and Data Storage services. There are a couple of components under test (Conferencing and a custom component we’re calling test.service) that are currently deactivated. There are also Logging services in their standard configuration. The components providing facilities for connecting to other Jabber servers—Server (to Server) Connections and Hostname Resolution—are currently inactive, meaning that as configured, the Jabber server will be purely internal. There’s a local JUD defined too; and finally we have the io and pidfile specifications—also abstracted out into separate XML chunks.

This works well especially if there are certain parts of the configuration—for example, certain component instance definitions—that don’t normally change; you can see that many of the component configuration files are in a “standard” directory, which by convention could signify that they’re the same as the XML configuration as delivered and are not likely to change.