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 <[email protected]>: > 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 <[email protected]> > 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é >> <[email protected]> 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 <[email protected]> >>> > 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 <[email protected]>: >>> > > 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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
