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