RFC: text pre-processing in OpenSIPS cfg file

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: text pre-processing in OpenSIPS cfg file

Bogdan-Andrei Iancu-2
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
    - you may have a mismatch for the line number (if errors reported in cfg) between the .m4 file and .cfg file

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.

Thanks and regards,
Bogdan

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Nick Altmann
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.

--
Nick


2012/4/10 Bogdan-Andrei Iancu <[hidden email]>:

> 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
>     - you may have a mismatch for the line number (if errors reported in
> cfg) between the .m4 file and .cfg file
>
> 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.
>
> Thanks and regards,
> Bogdan
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Ali Pey
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.

Regards,
Ali


On Tue, Apr 10, 2012 at 12:05 PM, Nick Altmann <[hidden email]> 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.

--
Nick


2012/4/10 Bogdan-Andrei Iancu <[hidden email]>:
> 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
>     - you may have a mismatch for the line number (if errors reported in
> cfg) between the .m4 file and .cfg file
>
> 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.
>
> Thanks and regards,
> Bogdan
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Ali Pey
Saúl,

It's very simple to define a simple text pre-processor. It would be one with only basic text/macro replacement with no fancy features.

I can understand that it would make more sense for you to use m4, but I don't understand how this would stop you from doing that? Your personal preference doesn't have to change.

It's all about simplicity. It would make it one or two steps shorter, faster and simpler for people that are not quite familiar with m4 or have simple requirements. Not every user is an expert.

Ali
 

On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Bogdan-Andrei Iancu-2
Well, it is not only about personal preferences and how is nicer, etc...you should consider also the required work to do - at the end somebody has to implement this. And my questions is: considering that the development resources are limited, does it make sense to invest them in just creating an alternative to something already existing ?

Regards,
Bogdan

On 04/11/2012 05:04 PM, Ali Pey wrote:
Saúl,

It's very simple to define a simple text pre-processor. It would be one with only basic text/macro replacement with no fancy features.

I can understand that it would make more sense for you to use m4, but I don't understand how this would stop you from doing that? Your personal preference doesn't have to change.

It's all about simplicity. It would make it one or two steps shorter, faster and simpler for people that are not quite familiar with m4 or have simple requirements. Not every user is an expert.

Ali
 

On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

klpauba
In reply to this post by Bogdan-Andrei Iancu-2

My opinion is to stick with M4.   Where's the added value in re-implementing a small subset of M4's capability into OpenSIPs?  I would rather that development effort be directed toward enhancing OpenSIPs even more.

 

Leaning m4 can make the management of multiple configurations a breeze -- I support four different environments (development, QA, pre-production and production) across 5 geo-redundant data centers all with a single .m4 file.  The use of m4 has _greatly_ simplifies the logic that I have to maintain.  After learning m4, you can apply that knowledge to other projects (code generators).

 

Granted, the quoting in m4 takes a bit getting used to but I feel that any sufficiently powerful macro language would have to have something similar.  If not, it wouldn't be sufficiently powerful enough for my uses.

 

Thanks

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan-Andrei Iancu
Sent: Tuesday, April 10, 2012 10:50 AM
To: [hidden email]
Subject: [OpenSIPS-Users] RFC: text pre-processing in OpenSIPS cfg file

 

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
    - you may have a mismatch for the line number (if errors reported in cfg) between the .m4 file and .cfg file

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.

Thanks and regards,
Bogdan


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu-2
On Wed, Apr 11, 2012 at 10:41 AM, Bogdan-Andrei Iancu
<[hidden email]> wrote:
> Well, it is not only about personal preferences and how is nicer, etc...you
> should consider also the required work to do - at the end somebody has to
> implement this. And my questions is: considering that the development
> resources are limited, does it make sense to invest them in just creating an
> alternative to something already existing ?
>

I honestly didn't like using M4. And it's not an opensips thing, it's
an M4 thing. I just don't like M4. I'm sure it can be attributed to me
not really knowing it, but I found that I couldn't really do what I
wanted with it without some sort of hacking. I wanted to do
conditional includes and such. Maybe all I needed was some good
examples.

Is there anyway to build m4 into the opensips pre-processor? so
opensips can just run the m4 file?
-Brett

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Rudy
In reply to this post by Bogdan-Andrei Iancu-2
Bogdan,

 You are absolutely correct about developmental resources and the limited availability of them. Thinking this in to account I think what would be needed isn't something complex, and things like substitutions, that just does not make sense to me. Whats missing is something simple like defines and if statements to switch things on/off based on defines or command line arguments. Flipping the question, what kind of functionality could be implemented with a day? This kind of feature needs a developmental time limit, or maybe even just some time to write a spec and let someone else fill the request with a patch.

 I agree with the comment about m4 quoting. Maybe this can be achieved by better integrating opensips with a preprocessor tool out of the box( be it m4, cpp or gpp). There are several simple pre-processors (hopefully not m4) that are available on most distributions via apt or yum or what have you. This method was suggested previously and I think Brett just mentioned it also. 

Thanks in advance,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )


On Wed, Apr 11, 2012 at 11:41 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Well, it is not only about personal preferences and how is nicer, etc...you should consider also the required work to do - at the end somebody has to implement this. And my questions is: considering that the development resources are limited, does it make sense to invest them in just creating an alternative to something already existing ?

Regards,
Bogdan


On 04/11/2012 05:04 PM, Ali Pey wrote:
Saúl,

It's very simple to define a simple text pre-processor. It would be one with only basic text/macro replacement with no fancy features.

I can understand that it would make more sense for you to use m4, but I don't understand how this would stop you from doing that? Your personal preference doesn't have to change.

It's all about simplicity. It would make it one or two steps shorter, faster and simpler for people that are not quite familiar with m4 or have simple requirements. Not every user is an expert.

Ali
 

On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Nick Altmann
But it's not necessary to do this work by core team.
I can implement all of defs, subs, if my patches will be applied.
It doesn't require resources of core team.

--
Nick


2012/4/11 Rudy <[hidden email]>:

> Bogdan,
>
>  You are absolutely correct about developmental resources and the
> limited availability of them. Thinking this in to account I think what would
> be needed isn't something complex, and things like substitutions, that just
> does not make sense to me. Whats missing is something simple like defines
> and if statements to switch things on/off based on defines or command line
> arguments. Flipping the question, what kind of functionality could
> be implemented with a day? This kind of feature needs a developmental time
> limit, or maybe even just some time to write a spec and let someone else
> fill the request with a patch.
>
>  I agree with the comment about m4 quoting. Maybe this can be achieved by
> better integrating opensips with a preprocessor tool out of the box( be it
> m4, cpp or gpp). There are several simple pre-processors (hopefully not m4)
> that are available on most distributions via apt or yum or what have you.
> This method was suggested previously and I think Brett just mentioned it
> also.
>
> Thanks in advance,
> --Rudy
> Dynamic Packet
> Toll-Free: 888.929.VOIP ( 8647 )
>
>
>
> On Wed, Apr 11, 2012 at 11:41 AM, Bogdan-Andrei Iancu <[hidden email]>
> wrote:
>>
>> Well, it is not only about personal preferences and how is nicer,
>> etc...you should consider also the required work to do - at the end somebody
>> has to implement this. And my questions is: considering that the development
>> resources are limited, does it make sense to invest them in just creating an
>> alternative to something already existing ?
>>
>> Regards,
>> Bogdan
>>
>>
>> On 04/11/2012 05:04 PM, Ali Pey wrote:
>>
>> Saúl,
>>
>> It's very simple to define a simple text pre-processor. It would be one
>> with only basic text/macro replacement with no fancy features.
>>
>> I can understand that it would make more sense for you to use m4, but I
>> don't understand how this would stop you from doing that? Your personal
>> preference doesn't have to change.
>>
>> It's all about simplicity. It would make it one or two steps shorter,
>> faster and simpler for people that are not quite familiar with m4 or have
>> simple requirements. Not every user is an expert.
>>
>> Ali
>>
>>
>> On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé
>> <[hidden email]> wrote:
>>>
>>> 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 <[hidden email]>
>>> > 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 <[hidden email]>:
>>> > > 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

klpauba
In reply to this post by Brett Nemeroff
The GNU M4 Manual gives lots of simple examples.  Reading the two (very short) sections http://www.gnu.org/software/m4/manual/m4.html#Ifdef and http://www.gnu.org/software/m4/manual/m4.html#Include, you can do something like this:

define(`foo',1)
ifdef(`foo',include(`foo.m4'))

But it's really hard to sway the "don't like" argument -- I don't like beef liver and nothing you say will change my mind.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Brett Nemeroff
Sent: Wednesday, April 11, 2012 10:54 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] RFC: text pre-processing in OpenSIPS cfg file

On Wed, Apr 11, 2012 at 10:41 AM, Bogdan-Andrei Iancu
<[hidden email]> wrote:
> Well, it is not only about personal preferences and how is nicer, etc...you
> should consider also the required work to do - at the end somebody has to
> implement this. And my questions is: considering that the development
> resources are limited, does it make sense to invest them in just creating an
> alternative to something already existing ?
>

I honestly didn't like using M4. And it's not an opensips thing, it's
an M4 thing. I just don't like M4. I'm sure it can be attributed to me
not really knowing it, but I found that I couldn't really do what I
wanted with it without some sort of hacking. I wanted to do
conditional includes and such. Maybe all I needed was some good
examples.

Is there anyway to build m4 into the opensips pre-processor? so
opensips can just run the m4 file?
-Brett

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Nick Altmann
I use now m4 on my opensips servers and I used internal macro
processing of openser before.
I can say that I prefer to have no external tools.
I need only substitutes and includes. No defines and other features.
In my case it's better to use simple internal macro processor than external.

Why not to have both possibilities?

--
Nick


2012/4/11 Pauba, Kevin L <[hidden email]>:

> The GNU M4 Manual gives lots of simple examples.  Reading the two (very short) sections http://www.gnu.org/software/m4/manual/m4.html#Ifdef and http://www.gnu.org/software/m4/manual/m4.html#Include, you can do something like this:
>
> define(`foo',1)
> ifdef(`foo',include(`foo.m4'))
>
> But it's really hard to sway the "don't like" argument -- I don't like beef liver and nothing you say will change my mind.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Brett Nemeroff
> Sent: Wednesday, April 11, 2012 10:54 AM
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] RFC: text pre-processing in OpenSIPS cfg file
>
> On Wed, Apr 11, 2012 at 10:41 AM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>> Well, it is not only about personal preferences and how is nicer, etc...you
>> should consider also the required work to do - at the end somebody has to
>> implement this. And my questions is: considering that the development
>> resources are limited, does it make sense to invest them in just creating an
>> alternative to something already existing ?
>>
>
> I honestly didn't like using M4. And it's not an opensips thing, it's
> an M4 thing. I just don't like M4. I'm sure it can be attributed to me
> not really knowing it, but I found that I couldn't really do what I
> wanted with it without some sort of hacking. I wanted to do
> conditional includes and such. Maybe all I needed was some good
> examples.
>
> Is there anyway to build m4 into the opensips pre-processor? so
> opensips can just run the m4 file?
> -Brett
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Ali Pey
In reply to this post by Bogdan-Andrei Iancu-2
I see your argument Bogdan and it makes sense. I agree that this wouldn't be a high priority feature. I personally use m4 and will have to use m4 since the same configuration file is used for all my software components including opensips. 

Do you keep of a list of features that you are considering for the next release? 

Regards,
Ali

On Wed, Apr 11, 2012 at 11:41 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Well, it is not only about personal preferences and how is nicer, etc...you should consider also the required work to do - at the end somebody has to implement this. And my questions is: considering that the development resources are limited, does it make sense to invest them in just creating an alternative to something already existing ?

Regards,
Bogdan


On 04/11/2012 05:04 PM, Ali Pey wrote:
Saúl,

It's very simple to define a simple text pre-processor. It would be one with only basic text/macro replacement with no fancy features.

I can understand that it would make more sense for you to use m4, but I don't understand how this would stop you from doing that? Your personal preference doesn't have to change.

It's all about simplicity. It would make it one or two steps shorter, faster and simpler for people that are not quite familiar with m4 or have simple requirements. Not every user is an expert.

Ali
 

On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Saúl Ibarra Corretgé
In reply to this post by Nick Altmann

On Apr 11, 2012, at 7:02 PM, Nick Altmann wrote:

> But it's not necessary to do this work by core team.
> I can implement all of defs, subs, if my patches will be applied.
> It doesn't require resources of core team.
>

The core team would probably review your patches, that takes resources. If you are not available to maintain those pieces of code any longer who will? That takes resources.

It will not be a one-liner, will it? :-)

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: text pre-processing in OpenSIPS cfg file

Bogdan-Andrei Iancu-2
In reply to this post by Ali Pey
Hi Ali,

We have not compiled yet the list for 1.9 (it will be published later after 1.8.0 becomes full stable). Currently we are working in 3 directions:
    1) 1.8.0 from beta to full stable - fixing bugs
    2) 2.0 - adding async DB support
    3) 1.9.0 still planning - mainly a distributed support for usrloc and dialog modules

Regards,
Bogdan

On 04/11/2012 10:07 PM, Ali Pey wrote:
I see your argument Bogdan and it makes sense. I agree that this wouldn't be a high priority feature. I personally use m4 and will have to use m4 since the same configuration file is used for all my software components including opensips. 

Do you keep of a list of features that you are considering for the next release? 

Regards,
Ali

On Wed, Apr 11, 2012 at 11:41 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Well, it is not only about personal preferences and how is nicer, etc...you should consider also the required work to do - at the end somebody has to implement this. And my questions is: considering that the development resources are limited, does it make sense to invest them in just creating an alternative to something already existing ?

Regards,
Bogdan


On 04/11/2012 05:04 PM, Ali Pey wrote:
Saúl,

It's very simple to define a simple text pre-processor. It would be one with only basic text/macro replacement with no fancy features.

I can understand that it would make more sense for you to use m4, but I don't understand how this would stop you from doing that? Your personal preference doesn't have to change.

It's all about simplicity. It would make it one or two steps shorter, faster and simpler for people that are not quite familiar with m4 or have simple requirements. Not every user is an expert.

Ali
 

On Tue, Apr 10, 2012 at 4:36 PM, Saúl Ibarra Corretgé <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>:
> > 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com



-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users