On 12/12/08 20:11, Andrei Pelinescu-Onciul wrote:
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.
Just to be sure there is no misunderstanding, by operators I meant "sip/voip service operators". It is harder to get skilled personnel than buying hardware, sip/voip is an area that lacks of good specialists, adding more on top of that could turn against.
Although I agree with you in most of the aspects and like strict checking (hehhh, C developer habits), I wanted to play devil's advocate, not to fall in our own trap. I was one those pushing the config language for flexibility, rather than embedding specific functionalities behind some c-coded functions and make configuration easier.
However, today's complexity of the config language is well-known to be heavy to digest for new comers. I admit, it is a trade off, but we need to take in consideration the target users (voip sysadmins), where still many have telco background rather than computer science.
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.
My comments were related to the general topic, perhaps the text I left in the message and commented by me got out of the context and didn't suggest it properly. Actually, in this particular case, I was thinking at types for variables, might be a bit too much for now...
As a matter of fact, I am in favor of "." for string concatenation, then will be clear delimitation what are the string and arithmetic operators (well, it is only one for strings). It will remove the ambiguity in some cases: $x . $y $x + $y
There are (pseudo-)variables that can return string and int at same time (e.g., port).
Mope my comments are more clear now!
Cheers, Daniel
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev