Introduction

ejabberd internal modules works as plugins. Each module is an erlang module with a name beginning with "mod_".

API of the module

All the internal modules must use the "gen_mod" behavior.

It must provide the following API:

start(Host, Opts) -> ok
stop(Host) -> ok
* Host = string()
* Opts = [{Name, Value}]
* Name = Value = sting()

Host is the name of the virtual host running the module. The start/2 and stop/1 functions are called for each virtual host at start and stop time of the server.
Opts is a lists of options set in the configuration file for the module. They can be retrieved with the gen_mod:get_opt/3 function.

ejabberd API

The modules interact with ejabberd using one or several of the following mechanisms:

• Core modules: Most useful API functions from the core ejabberd modules.
• Events and hooks: ejabberd provides an event mechanism. Each module can subscribe to events and a hook in the module code is called when the event occurs.
• IQ handlers: ejabberd internal modules can register themselves to handle IQ using a specific namespace, in a way similar to the hooks mechanism.
• Route table: ejabber internal modules can add themselves to the route table of the server with an XMPP name. These modules are known as "services".

Running an internal module as an external module=C2=A0

ejabberd internal modules using only the route table can also be used as external modules conform to XEP-0114 (Jabber Component Protocol) with epeios, and thus, they can be used with any other XEP-0114 compliant XMPP servers.