[OpenSIPS-Users] RFC: text pre-processing in OpenSIPS cfg file

[Saúl Ibarra Corretgé]

Hi all,

On Apr 10, 2012, at 6:13 PM, Ali Pey wrote:

> I also think it would be a great addition to have a simple build-in text pre-processing. For more advance features people can continue to use m4 as desired.
> 

The problem is the word "simple" on your sentence :-) How do we tell if a feature request qualifies as "simple" or not?

For me, the config file is fine as it is. It does have limitations, but m4 helps in solving them.

> Regards,
> Ali
> 
> 
> On Tue, Apr 10, 2012 at 12:05 PM, Nick Altmann <nick.altmann at gmail.com> wrote:
> Against for M4:
> Configuration file may not be generated properly from m4 file(s)
> sometimes (because missed errors in m4), then server cannot start in
> some cases. It's when m4 in init.d script. When cfg-file built from m4
> manually, it's uncomfortable.
> 
> In my opinion, opensips is the most powerful sip server, so it should
> have both options. And users should make decision which to better use
> in each case.
> 

You should not attempt to run OpenSIPS with the new generated file before testing it, you may have made a silly typo and the server would be stopped. You can do it in 2 steps:

- Regenerate the cfg file from the m4 files and call use opensips -c to validate the config file
- Restart the service if the config was valid

> 
> 2012/4/10 Bogdan-Andrei Iancu <bogdan at opensips.org>:
> > Hi,
> >
> > I'm bringing here a discussion started on devel list, as I would like to get
> > more opinions on the matter.
> >
> > The discussion started around the decision if makes sense to have MACRO
> > substitution (as text pre-processing) directly in OpenSIPS, considering that
> > right now M4 is heavenly used for this (as additional tool to opensips).
> >
> > So, the debate was : have built-in text pre-processing versus using M4 as
> > text processor
> >
> > Pros for M4:
> >     - no effort to develop extra stuff - just install M4
> >     - can do really complex things (more than only macros, ifdef, include,
> > etc)
> >     - you can use it or not
> >     - easy to integrate with start / stop scripts
> > Against for M4:
> >     - need to be installed and integrated

I'm not aware of any system where installing m4 is troublesome.

> >     - you may have a mismatch for the line number (if errors reported in
> > cfg) between the .m4 file and .cfg file
> >

While this is true, you can look at the generated cfg file, and leaving comments is also a good idea ;-)

> > Pros for buit-in:
> >     - you do no need to install M4 at all (everything comes packet)
> >     - you may get accurate reporting on errors (for line in cfg)
> > Against for M4:
> >     - more devel work to re-implement macros, ifdef, etc
> >
> >
> > Now, I would like to get your opinions on that (you as opensips users), to
> > see if we stick to using M4 for cfg pre-processing or there is a real need
> > to have this functionality as built-in.
> >

As I said in the other thread I think that using resources for enhancing the current configuration language is not a good idea. Ideally I'd like to program my routing logic in a real programming language like Python, Lua or Ruby not something totally different which newcomers need to learn and is not a fully blown programing language.

M4 is a powerful tool which can be used together with the current configuration language to achieve all the requirements mentioned in the previous mail, without modifying OpenSIPS.

Maybe it would be a good idea to use m4 in the sample configs? Having a opensips.m4 file with the main routing logic and some local.m4 file with custom settings like DB configs, etc could help people get their feet wet with m4. Even adding a "opensipsctl reconfigure" command could make sense, it could just do the following:

pushd /etc/opensips
m4 opensips.m4 > opensips.cfg
opensips -c /etc/opensips/opensips.cfg
popd

So if there is an error you could see it before actually attempting to run OpenSIPS with the change applied.

Those are my 2 cents :-)


Regards,

--
Saúl Ibarra Corretgé
AG Projects