[SR-Dev] operators and variables

[Daniel-Constantin Mierla]

On 12/12/08 20:11, Andrei Pelinescu-Onciul wrote:
> On Dec 12, 2008 at 17:23, Daniel-Constantin Mierla <miconda at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com