On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/12/08 16:43, Andrei Pelinescu-Onciul wrote:
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.
We are not talking about extremes, we are talking about making it more perl like (which is a very common scripting language).
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