Hi Ali,
We have not compiled yet the list for 1.9 (it will be published later
after 1.8.0 becomes full stable). Currently we are working in 3 directions:
1) 1.8.0 from beta to full stable - fixing bugs
2) 2.0 - adding async DB support
3) 1.9.0 still planning - mainly a distributed support for usrloc
and dialog modules
Regards,
Bogdan
On 04/11/2012 10:07 PM, Ali Pey wrote:
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] <mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
--
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
