Bogdan,<div><br></div><div> 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&#39;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.</div>

<div><br></div><div> 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. </div>

<div><br clear="all">Thanks in advance,<br>--Rudy<br>Dynamic Packet<br>Toll-Free: 888.929.VOIP ( 8647 )<br>
<br><br><div class="gmail_quote">On Wed, Apr 11, 2012 at 11:41 AM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<u></u>

  
    
  
  <div bgcolor="#ffffff" text="#000000">
    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 ?<br>
    <br>
    Regards,<br>
    Bogdan<div><div><br>
    <br>
    On 04/11/2012 05:04 PM, Ali Pey wrote:
    <blockquote type="cite">Saúl,
      <div><br>
      </div>
      <div>It&#39;s very simple to define a simple text pre-processor. It
        would be one with only basic text/macro replacement with no
        fancy features.</div>
      <div><br>
      </div>
      <div>I can understand that it would make more sense for you to use
        m4, but I don&#39;t understand how this would stop you from doing
        that? Your personal preference doesn&#39;t have to change.</div>
      <div><br>
      </div>
      <div>It&#39;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.</div>
      <div><br>
      </div>
      <div>Ali</div>
      <div> </div>
      <div><br>
        <div class="gmail_quote">On Tue, Apr 10, 2012 at 4:36 PM, Saúl
          Ibarra Corretgé <span dir="ltr">&lt;<a href="mailto:saul@ag-projects.com" target="_blank">saul@ag-projects.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
            <div><br>
              On Apr 10, 2012, at 6:13 PM, Ali Pey wrote:<br>
              <br>
              &gt; 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.<br>
              &gt;<br>
              <br>
            </div>
            The problem is the word &quot;simple&quot; on your sentence :-) How do
            we tell if a feature request qualifies as &quot;simple&quot; or not?<br>
            <br>
            For me, the config file is fine as it is. It does have
            limitations, but m4 helps in solving them.<br>
            <div><br>
              &gt; Regards,<br>
              &gt; Ali<br>
              &gt;<br>
              &gt;<br>
              &gt; On Tue, Apr 10, 2012 at 12:05 PM, Nick Altmann &lt;<a href="mailto:nick.altmann@gmail.com" target="_blank">nick.altmann@gmail.com</a>&gt;
              wrote:<br>
              &gt; Against for M4:<br>
              &gt; Configuration file may not be generated properly from
              m4 file(s)<br>
              &gt; sometimes (because missed errors in m4), then server
              cannot start in<br>
              &gt; some cases. It&#39;s when m4 in init.d script. When
              cfg-file built from m4<br>
              &gt; manually, it&#39;s uncomfortable.<br>
              &gt;<br>
              &gt; In my opinion, opensips is the most powerful sip
              server, so it should<br>
              &gt; have both options. And users should make decision
              which to better use<br>
              &gt; in each case.<br>
              &gt;<br>
              <br>
            </div>
            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:<br>
            <br>
            - Regenerate the cfg file from the m4 files and call use
            opensips -c to validate the config file<br>
            - Restart the service if the config was valid<br>
            <div><br>
              &gt;<br>
              &gt; 2012/4/10 Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>&gt;:<br>
              &gt; &gt; Hi,<br>
              &gt; &gt;<br>
              &gt; &gt; I&#39;m bringing here a discussion started on devel
              list, as I would like to get<br>
              &gt; &gt; more opinions on the matter.<br>
              &gt; &gt;<br>
              &gt; &gt; The discussion started around the decision if
              makes sense to have MACRO<br>
              &gt; &gt; substitution (as text pre-processing) directly
              in OpenSIPS, considering that<br>
              &gt; &gt; right now M4 is heavenly used for this (as
              additional tool to opensips).<br>
              &gt; &gt;<br>
              &gt; &gt; So, the debate was : have built-in text
              pre-processing versus using M4 as<br>
              &gt; &gt; text processor<br>
              &gt; &gt;<br>
              &gt; &gt; Pros for M4:<br>
              &gt; &gt;     - no effort to develop extra stuff - just
              install M4<br>
              &gt; &gt;     - can do really complex things (more than
              only macros, ifdef, include,<br>
              &gt; &gt; etc)<br>
              &gt; &gt;     - you can use it or not<br>
              &gt; &gt;     - easy to integrate with start / stop
              scripts<br>
              &gt; &gt; Against for M4:<br>
              &gt; &gt;     - need to be installed and integrated<br>
              <br>
            </div>
            I&#39;m not aware of any system where installing m4 is
            troublesome.<br>
            <div><br>
              &gt; &gt;     - you may have a mismatch for the line
              number (if errors reported in<br>
              &gt; &gt; cfg) between the .m4 file and .cfg file<br>
              &gt; &gt;<br>
              <br>
            </div>
            While this is true, you can look at the generated cfg file,
            and leaving comments is also a good idea ;-)<br>
            <div><br>
              &gt; &gt; Pros for buit-in:<br>
              &gt; &gt;     - you do no need to install M4 at all
              (everything comes packet)<br>
              &gt; &gt;     - you may get accurate reporting on errors
              (for line in cfg)<br>
              &gt; &gt; Against for M4:<br>
              &gt; &gt;     - more devel work to re-implement macros,
              ifdef, etc<br>
              &gt; &gt;<br>
              &gt; &gt;<br>
              &gt; &gt; Now, I would like to get your opinions on that
              (you as opensips users), to<br>
              &gt; &gt; see if we stick to using M4 for cfg
              pre-processing or there is a real need<br>
              &gt; &gt; to have this functionality as built-in.<br>
              &gt; &gt;<br>
              <br>
            </div>
            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&#39;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.<br>
            <br>
            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.<br>
            <br>
            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 &quot;opensipsctl reconfigure&quot; command could make
            sense, it could just do the following:<br>
            <br>
            pushd /etc/opensips<br>
            m4 opensips.m4 &gt; opensips.cfg<br>
            opensips -c /etc/opensips/opensips.cfg<br>
            popd<br>
            <br>
            So if there is an error you could see it before actually
            attempting to run OpenSIPS with the change applied.<br>
            <br>
            Those are my 2 cents :-)<br>
            <br>
            <br>
            Regards,<br>
            <br>
            --<br>
            Saúl Ibarra Corretgé<br>
            AG Projects<br>
            <div>
              <div><br>
                <br>
                <br>
                <br>
                _______________________________________________<br>
                Users mailing list<br>
                <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
                <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
    <br>
    </div></div><div><pre cols="72">-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
  </div></div>

<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>