12 Dec
2008
12 Dec
'08
7:11 p.m.
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 12/12/08 16:43, Andrei Pelinescu-Onciul wrote:
We are not talking about extremes, we are talking about making it more
perl like (which is a very common scripting language).
It brings less performance then the operators
changes, but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).
we should be careful and not get into extremes here. Performance shall
not ignore the complexity added in writing config -- ending to write the
config in C-like language should be avoided. While here are developers,
those using/administrating sip servers might be far from this
background. Easiness in understanding the config language and writing
the scripts by non-devels is very important to make it spread faster in
the market.
For operators, buying another server for one time 1-2k bucks is cheaper
than one full time developer that sits to optimize month by month.
People would only need to use '.' for string and '+' for ints, they
don't need to do any optimization. The optimization will be done
automatically for them (already a lot of things are optimized), so I
fail to see your point.
In my opinion we should not aim to build a scripting language which is
easier then basic perl, especially since for us performance is much more
critical. I also fail to see the great concern about the extra
complexity a new operator would introduce. Any error will be reported
immediately and could be self explaining (like: wrong operator for
string, try '.').
Moreover as I already said this is not only about performance, is about
proper error checking before startup. I don't think anybody wants to
find bugs in his script in production, because he forgot that some avp
had int type and he tried to add it to a string... Right now this
script bug cannot be found. With the proposed changes it would be
reported immediately (sr -cf config will catch it, and also sr will
refuse to start if such an error is found).
If that's about compatibility with existing scripts, then let's leave
'+' for the next version and add '.' in parallel and at some future time
we'll obsolete '+' usage for strings.
The typed vars are for the future anyway.
Andrei