From openSIPS

Development: OpenSIPS Script Preprocessor Design

Development -> Planning -> OpenSIPS Script Preprocessor Design

This page has been visited 2552 times.

1.  Motivation

There is not a shade of doubt that real-life systems based on OpenSIPS require a templating language or a preprocessor to be used in order to generate the opensips.cfg file. When you have to deploy almost identical opensips.cfg files to tens of servers which only differ by a few IP addresses, ports, unique IDs, etc., having a macro to encompass these variable pieces of text goes a long way. But why isn't a solution like the GNU m4 preprocessor (which offers the above) the perfect fit for this task?

There are two major inconveniences when working with external tools such as GNU m4:

• the opensips.cfg error log lines do not have a 1:1 correspondence with the opensips.cfg.m4 file. For example, OpenSIPS may report an opensips.cfg error at line 432, which actually corresponds to line 391 in opensips.cfg.m4 due to some foreach templating statement which generated additional LoC.
• you have to pay extra attention when working with two files: opensips.cfg.m4 and opensips.cfg. Sometimes, the user mistakenly performs configuration changes on the opensips.cfg file then restarts the opensips instance, thus losing all the work, since opensips.cfg gets re-generated.

2.  Often-Required Features

Below is a community-sourced summary of commonly required templating features to be used on top of opensips.cfg:

• simple macro definitions (textual substitution)
• conditional groups (e.g. "ifdef ... <code> ... endif")
• parameterized macro definitions
• generative loops (e.g. "for each <address> in <list_of_interfaces>, plug in <this code>")

3.  Directions Under Scrutiny

We ultimately require a C library or framework which would allow us to build the above features directly into the OpenSIPS scripting language. This way, OpenSIPS will be able to internally preprocess the "opensips.cfg" file without breaking the line numbering or introducing additional cumbersome files to work with!

Currently, we're looking at the following directions:

• GNU m4 (does it have C language bindings? Forking an m4 process is not an answer!)
• .erb (Embedded Ruby. Any C bindings?)
• .j2 (Jinja2. Any C bindings?)

4.  Confirmed Solutions

TBD

5.  Have a Better Idea?

If you have ideas which help solve the core problems, we are here to listen! Please feel free to reply below, or on the users mailing list thread!