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

Wed Apr 11 19:02:33 CEST 2012

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 <rudy at dynamicpacket.com>:
> 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 <bogdan at opensips.org>
> 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é
>> <saul at ag-projects.com> 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 <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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>