[OpenSIPS-Users] RFC: text pre-processing in OpenSIPS cfg file
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Apr 11 17:41:11 CEST 2012
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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120411/052261d0/attachment.htm>
More information about the Users
mailing list