Page Comparison

{xxfuture}

*This page describes how the configuration of C++ plugins is changing in 4.3.*

{note}
The interface to a plugin, including how it reads its own configuration data, has not changed at all; this scheme is fully backwards compatible with the implementation of any plugin in version 4.2.
{note}

There are 4 parts to the configuration for a plugin (with the colors used for them below):

* The hook that the plugin module should be called by (effectively what subclass of 'Plugin' it is);  {color:red}shown in red{color}.
* The name of the plugin instance (it is possible to configure more than one copy of the same plugin with different names, each with its configuration values); {color:blue}shown in blue{color}
* The shared library that implements the plugin; {color:green}shown in green{color}
* Any configuration name/value pairs required by the plugin; {color:orange}shown in orange{color}

h1. Configuration File Names and Structure

h2. The Old Way

In 4.2 and earlier, all plugins for a component were configured by adding lines to the (single) {{\*\-config}} file for the component; in the case of the registrar, this is {{/etc/sipxpbx/registrar-config}}

Every plugin configuration required a line to configure the library, but parts of that line also provided the hook and the instance.  This configuration line was constructed as:
{panel}
{color:red}_hookname_{color}{{*\_HOOK\_LIBRARY.*}}{color:blue}_instancename_{color} : {color:green}_librarypath_{color}
{panel}

Each line in the configuration that matched that pattern configured the existence of a plugin instance and specified its library.  The line in the {{registrar-config}} file that adds the mapping rules redirector plugin is:
{panel}
{{{color:red}SIP_REDIRECT{color}*\_HOOK\_LIBRARY.*{color:blue}130-MAPPING{color} : {color:green}/usr/lib/libRedirectorMapping.so{color}}}
{panel}

If no configuration parameters are needed by the plugin, that that one line is all that was needed.  When the plugin needs parameters, the configuration lines for those values were constructed as:
{panel}
{color:red}_hookname_{color}{{*.*}}{color:blue}_instancename_{color}{{*.*}}{color:orange}_paramname_{color} : {color:orange}_paramvalue_{color}
{panel}

The directive that configures the file name for the mapping rules file name is:
{panel}
{{{color:red}SIP_REDIRECT{color}*.*{color:blue}130-MAPPING{color}*.*{color:orange}MAPPING_RULES_FILENAME{color} : {color:orange}/etc/sipxpbx/mappingrules.xml{color}}}
{panel}

h2. The New Way

In 4.3 each hook for a component has a directory into which a separate configuration file is written for each plugin instance.  So, for the registrar, which has two different plugin hooks, there will be two directories:
{panel}
{{/etc/sipxpbx/{color:red}redirect-hook{color}/}}
{{/etc/sipxpbx/{color:red}registrar-hook{color}/}}
{panel}

The individual plugin configuration file name is contructed using the instance name and the suffix {{.plugin}}:
{panel}
{color:blue}_instancename_{color}{{.plugin}}
{panel}

The contents of the plugin configuration files are simpler in the new scheme, since encoding the hook and instance names in the contents is not required.

To configure the library name every {{.plugin}} configuration file must contain at least a {{HOOK_LIBRARY}} value:
{panel}
{{*HOOK\_LIBRARY*}} : {color:green}_librarypath_{color}
{panel}
If no configuration parameters are needed by the plugin, then that one line is all that is needed.

When the plugin does need parameters, the configuration lines for those values are just the parameter name and value:
{panel}
{color:orange}_paramname_{color} : {color:orange}_paramvalue_{color}
{panel}

So, to add the mappingrules redirector plugin and assign its file name, the file {{/etc/sipxpbx/{color:red}redirect-hook{color}/{color:blue}130-mapping{color}.plugin}} is written:
{panel}
{{HOOK\_LIBRARY : {color:green}/usr/lib/libRedirectorMapping.so{color}}}
{{{color:orange}MAPPING_RULES_FILENAME{color} : {color:orange}/etc/sipxpbx/mappingrules.xml{color}}}
{panel}

h1. List of Plugins

*TBD*