12 Dec
2008
12 Dec
'08
9:32 p.m.
On 12/12/08 20:11, Andrei Pelinescu-Onciul wrote:
On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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.
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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com