replacing k pvars with s selects

[Juha Heinanen]

in order to clear lots of confusion and in order to simplify things, i'm
suggesting that we replace k pvars with s selects.  for example, $fd
would become @from.uri.host.  also, $avp(name) would simply become
$name.

-- juha

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 07/03/2009 06:15 PM, Juha Heinanen wrote:
> in order to clear lots of confusion
whose confusion? pv framework is pretty different that select, things
like $sht(htable=>key) a.s.o. do not reflect something in the sip
message. Besides that there are transformations behind them.

Lot of code and config depends on PV frameworks, so if you feel less
confused, just use select instead of PV, both are available, it is your
choice to use one of them. You can just not load pv module you have not
much to do with PVs.

Replacing is definitely not a viable option.

Daniel

>  and in order to simplify things, i'm
> suggesting that we replace k pvars with s selects.  for example, $fd
> would become @from.uri.host.  also, $avp(name) would simply become
> $name.
>  

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


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

On Fri, Jul 3, 2009 at 6:15 PM, Juha Heinanen<[hidden email]> wrote:
> in order to clear lots of confusion and in order to simplify things, i'm
> suggesting that we replace k pvars with s selects.  for example, $fd
> would become @from.uri.host.

Actually, what if we used the @ character as delimiter for PVs? I mean
SER selects and Kamailio PVs have the same purpose. This way they
would complement each other. All SER selects use long verbose
identifiers, while PVs use short identifiers, so the changes of
conflicts are minimized.

The script writer would then know that whatever starts with @ is a
special "variable" that is used to retrieve information from the SIP
message, operating system, transport layer, etc...

It would also be a good starting point for future integration, we
currently have many selects and PVs that are equivalent, i.e.
@from.uri.host and $fd. Later we can share the implementation and the
two could become aliases for to a common function. For example $fd
would be written as @fd and it would do the same as @from.uri.host.

If you don't like @ then we can also try to pick a new character and
migrate both, selects and PVs to a new character, such as &. This way
both implementations would be equally affected.

The bottom line is that we have two alternative implementation of the
same thing, they complement each other and it would help tremendously
if they used the same delimiter--different from AVPs and variables.

> also, $avp(name) would simply become
> $name.

Yes, the syntax would become shorter and the danger of conflicts would
be minimized.

It's just a proposal, we ran into this issue while we were trying to
unify the domain module. You can see this module as an early migration
bird, I suspect the issue of conflicting identifiers will be in many
other modules and we would have to tackle it somehow before we can
proceed further.

  Jan.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Juha Heinanen]

Daniel-Constantin Mierla writes:

 > whose confusion?

like the discussion on lookup_domain function revealed, it is confusing
that the same prefix ($ char) is used for two different things.

 > Lot of code and config depends on PV frameworks, so if you feel less
 > confused, just use select instead of PV, both are available, it is your
 > choice to use one of them. You can just not load pv module you have not
 > much to do with PVs.

that indeed is a viable option.

-- juha

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin
Mierla<[hidden email]> wrote:
>
>
> On 07/03/2009 06:15 PM, Juha Heinanen wrote:
>>
>> in order to clear lots of confusion
>
> whose confusion? pv framework is pretty different that select, things like
> $sht(htable=>key) a.s.o. do not reflect something in the sip message.

The thing that started this is "$fd". If you see "$fd" written in the
sip-router configuration file, how can you tell whether this is an AVP
or a PV? The answer is you cannot, unless you look into the
implementation.

This is a burning issue in many modules. It is not a problem as long
as you only use kamailio modules or only ser modules, but it become
apparent when we try to mix them.

  Jan.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 07/03/2009 06:36 PM, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>  > whose confusion?
>
> like the discussion on lookup_domain function revealed, it is confusing
> that the same prefix ($ char) is used for two different things.
>  

from my point of view, all are script variables: avps, references to sip
message parts, etc ... therefore the have to start with same char, and
most of the programming languages use $ for that. It is what was decided
long time ago in openser when pseudo-variables were introduced in core.

Basically, there are classes of script variables, some accepting dynamic
names (like avps $avp(...), headers $hdr(...), private $var(...) and
shared variables $sht(...) a.s.o.).

I do not see reason for a special character for certain classes, like
avp or select. It is much much clearer to have:
$avp(name)
$sel(name)

rather than:
$name for avps
@name for selects
&name, %name etc. for what so ever variable class

Daniel


>  > Lot of code and config depends on PV frameworks, so if you feel less
>  > confused, just use select instead of PV, both are available, it is your
>  > choice to use one of them. You can just not load pv module you have not
>  > much to do with PVs.
>
> that indeed is a viable option.
>
> -- juha
>  

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


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Andrei Pelinescu-Onciul]

On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla <[hidden email]> wrote:

>
>
> On 07/03/2009 06:36 PM, Juha Heinanen wrote:
> >Daniel-Constantin Mierla writes:
> >
> > > whose confusion?
> >
> >like the discussion on lookup_domain function revealed, it is confusing
> >that the same prefix ($ char) is used for two different things.
> >  
>
> from my point of view, all are script variables: avps, references to sip
> message parts, etc ... therefore the have to start with same char, and
> most of the programming languages use $ for that. It is what was decided
> long time ago in openser when pseudo-variables were introduced in core.

From my point of view the only things that are close to variables are
the avps and the script vars. All the others are in fact hidden function
calls and should be syntactically different.

>
> Basically, there are classes of script variables, some accepting dynamic
> names (like avps $avp(...), headers $hdr(...), private $var(...) and
> shared variables $sht(...) a.s.o.).
>
> I do not see reason for a special character for certain classes, like
> avp or select. It is much much clearer to have:
> $avp(name)
> $sel(name)

We should use $ only for variables (like any other script language out
there). This doesn't mean avps though. The avps should be accessed in
some other distinct way. avps are both slow and they consume memory, so
their use as script vars should be discouraged.

>
> rather than:
> $name for avps
> @name for selects
> &name, %name etc. for what so ever variable class

I would use '$' only for fast script vars (that should be declared at
the beginning of the script and would be typed), and some function like
construct for the other (e.g.  $var=sel("from.uri")).


Andrei

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 07/03/2009 06:38 PM, Jan Janak wrote:

> On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin
> Mierla<[hidden email]> wrote:
>  
>> On 07/03/2009 06:15 PM, Juha Heinanen wrote:
>>    
>>> in order to clear lots of confusion
>>>      
>> whose confusion? pv framework is pretty different that select, things like
>> $sht(htable=>key) a.s.o. do not reflect something in the sip message.
>>    
>
> The thing that started this is "$fd". If you see "$fd" written in the
> sip-router configuration file, how can you tell whether this is an AVP
> or a PV? The answer is you cannot, unless you look into the
> implementation.
>  

probably the script writer that loads the pv module is aware of what it
exports and does: $name is looked up first as PV then as avp.

If the ser writer would use avp class prefix all the time e.g.: $f.name
for avps in from list instead of just $name, then it is really no
possible overlapping.

That will remove the possible typo errors with PV, in K if $name does
not exist (let's say I wrote $fx instead of $fd), then error is issued
at startup. Now is considered to be avp and possible to appear at runtime.

If $class.name is enforced in ser side, then we can get good startup
checking and no namespace overlapping.

Daniel

> This is a burning issue in many modules. It is not a problem as long
> as you only use kamailio modules or only ser modules, but it become
> apparent when we try to mix them.
>
>   Jan.
>  

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


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:

> On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla <[hidden email]> wrote:
>  
>> On 07/03/2009 06:36 PM, Juha Heinanen wrote:
>>    
>>> Daniel-Constantin Mierla writes:
>>>
>>>      
>>>> whose confusion?
>>>>        
>>> like the discussion on lookup_domain function revealed, it is confusing
>>> that the same prefix ($ char) is used for two different things.
>>>  
>>>      
>> from my point of view, all are script variables: avps, references to sip
>> message parts, etc ... therefore the have to start with same char, and
>> most of the programming languages use $ for that. It is what was decided
>> long time ago in openser when pseudo-variables were introduced in core.
>>    
>
> >From my point of view the only things that are close to variables are
> the avps

avps are not at all, if you put it this way. it is a linked list,
actually more like a stack, but via some options, elements that are not
in top, can be accessed.



>  and the script vars. All the others are in fact hidden function
> calls and should be syntactically different.
>  
All are function calls as long as the value can be int or string.

>> Basically, there are classes of script variables, some accepting dynamic
>> names (like avps $avp(...), headers $hdr(...), private $var(...) and
>> shared variables $sht(...) a.s.o.).
>>
>> I do not see reason for a special character for certain classes, like
>> avp or select. It is much much clearer to have:
>> $avp(name)
>> $sel(name)
>>    
>
> We should use $ only for variables (like any other script language out
> there). This doesn't mean avps though. The avps should be accessed in
> some other distinct way. avps are both slow and they consume memory, so
> their use as script vars should be discouraged.
>
>  
>> rather than:
>> $name for avps
>> @name for selects
>> &name, %name etc. for what so ever variable class
>>    
>
> I would use '$' only for fast script vars (that should be declared at
> the beginning of the script and would be typed), and some function like
> construct for the other (e.g.  $var=sel("from.uri")).
>  

in shell you can have ${VAR:0:5}. Introducing of PV in openser core
started from %name used in xlog, but trying to follow shell var syntax.

Besides just nice to discuss, such changes makes no point now. Remember
the goal is to have a first version for each project that is easy to
migrate to from older ones. Therefore we committed to go for a best
compatibility approach. I hope we do not divert from here, otherwise
will be come a nightmare to get people on board with migration.

If someone has free time, no problem, he can start coding a new
framework that could obsolete PVs (and selects, a.s.o.) via better
design and functionality, keep both for a while, let other developers
update their code to the one that is more appealing and the users become
comfortable with syntax, etc...

PV framework impact to core is very minimalistic, I hoped same would
happen with selects, but not yet. Where two fit, it is place for the
third...

Daniel

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


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin
Mierla<[hidden email]> wrote:
>>  > whose confusion?
>> like the discussion on lookup_domain function revealed, it is confusing
>> that the same prefix ($ char) is used for two different things.
>>
>
> from my point of view, all are script variables: avps, references to sip
> message parts, etc ... therefore the have to start with same char, and most
> of the programming languages use $ for that. It is what was decided long
> time ago in openser when pseudo-variables were introduced in core.

Actually, those programming languages that use delimiting characters
for symbols often use different symbols for different categories of
symbols. See, for example, this wikipedia page for some examples and
historic perspective:

http://en.wikipedia.org/wiki/Sigil_(computer_programming)

Most of the pseudo variables, are, in fact, just hidden functions that
perform complex magic to retrieve a piece of information from the SIP
message, for example. This is definitely true for selects in SER and
it is, as far as I can tell, true for many of the PVs in Kamailio.

When it comes to selects in SER, they are basically nothing more than
just function names constructed in a special way. We use the '@'
delimiter at the beginning of the function name to denote that this is
a special kind of function which cannot be used like other function in
the routing part of the script. There is no reason why selects should
use the same delimiter that is used for variables (in case of SER AVPs
because there are no real variables).

> Basically, there are classes of script variables, some accepting dynamic
> names (like avps $avp(...), headers $hdr(...), private $var(...) and shared
> variables $sht(...) a.s.o.).
>
> I do not see reason for a special character for certain classes, like avp or
> select. It is much much clearer to have:
> $avp(name)
> $sel(name)

Why is it clearer to overload one delimiter for different kinds of
symbols than to use multiple delimiters? Under the hood, selects are
something completely different than AVPs. Pseudo variables like $fd
are something very different than $var(..), and so on.

And if this is the preferred approach, wouldn't it make more sense to
call functions as $func(name) as well? Just to be consistent?

> rather than:
> $name for avps
> @name for selects
> &name, %name etc. for what so ever variable class

This form is much more compact, easier to read, and also similar to
how other programming languages treat different categories of symbols.
Note that in your example above you do the same thing, only in a more
complex way.

   Jan.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 14.07.2009 15:54 Uhr, Jan Janak wrote:

> On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin
> Mierla<[hidden email]> wrote:
>  
>>>  > whose confusion?
>>> like the discussion on lookup_domain function revealed, it is confusing
>>> that the same prefix ($ char) is used for two different things.
>>>
>>>      
>> from my point of view, all are script variables: avps, references to sip
>> message parts, etc ... therefore the have to start with same char, and most
>> of the programming languages use $ for that. It is what was decided long
>> time ago in openser when pseudo-variables were introduced in core.
>>    
>
> Actually, those programming languages that use delimiting characters
> for symbols often use different symbols for different categories of
> symbols.

the alphabet is exhausted already if you think this way -- there are lot
of PV classes by now.

>  See, for example, this wikipedia page for some examples and
> historic perspective:
>
> http://en.wikipedia.org/wiki/Sigil_(computer_programming)
>
> Most of the pseudo variables, are, in fact, just hidden functions that
> perform complex magic to retrieve a piece of information from the SIP
> message, for example.
same is for avps - a hidden function accessing a linked list in shared
memory. Moreover, ser mode of avps encodes the list in the name (in K
there is only one avp list, while in S are couple of them). Further,
$shv(xyz) is accessing a fixed location in shared memory, $var(abc) is
accessing a fixed location is private memory, a.s.o. ... we can move all
to $ or all to @.

Daniel

>  This is definitely true for selects in SER and
> it is, as far as I can tell, true for many of the PVs in Kamailio.
>
> When it comes to selects in SER, they are basically nothing more than
> just function names constructed in a special way. We use the '@'
> delimiter at the beginning of the function name to denote that this is
> a special kind of function which cannot be used like other function in
> the routing part of the script. There is no reason why selects should
> use the same delimiter that is used for variables (in case of SER AVPs
> because there are no real variables).
>
>  
>> Basically, there are classes of script variables, some accepting dynamic
>> names (like avps $avp(...), headers $hdr(...), private $var(...) and shared
>> variables $sht(...) a.s.o.).
>>
>> I do not see reason for a special character for certain classes, like avp or
>> select. It is much much clearer to have:
>> $avp(name)
>> $sel(name)
>>    
>
> Why is it clearer to overload one delimiter for different kinds of
> symbols than to use multiple delimiters? Under the hood, selects are
> something completely different than AVPs. Pseudo variables like $fd
> are something very different than $var(..), and so on.
>
> And if this is the preferred approach, wouldn't it make more sense to
> call functions as $func(name) as well? Just to be consistent?
>
>  
>> rather than:
>> $name for avps
>> @name for selects
>> &name, %name etc. for what so ever variable class
>>    
>
> This form is much more compact, easier to read, and also similar to
> how other programming languages treat different categories of symbols.
> Note that in your example above you do the same thing, only in a more
> complex way.
>
>    Jan.
>
> _______________________________________________
> sr-dev mailing list
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>  

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

On Fri, Jul 3, 2009 at 7:25 PM, Daniel-Constantin
Mierla<[hidden email]> wrote:

>
>
> On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
>>
>> On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla <[hidden email]>
>> wrote:
>>
>>>
>>> On 07/03/2009 06:36 PM, Juha Heinanen wrote:
>>>
>>>>
>>>> Daniel-Constantin Mierla writes:
>>>>
>>>>
>>>>>
>>>>> whose confusion?
>>>>
>>>> like the discussion on lookup_domain function revealed, it is confusing
>>>> that the same prefix ($ char) is used for two different things.
>>>>
>>>
>>> from my point of view, all are script variables: avps, references to sip
>>> message parts, etc ... therefore the have to start with same char, and most
>>> of the programming languages use $ for that. It is what was decided long
>>> time ago in openser when pseudo-variables were introduced in core.
>>>
>>
>> >From my point of view the only things that are close to variables are
>> the avps
>
> avps are not at all, if you put it this way. it is a linked list, actually
> more like a stack, but via some options, elements that are not in top, can
> be accessed.
>
>
>
>>  and the script vars. All the others are in fact hidden function
>> calls and should be syntactically different.
>>
>
> All are function calls as long as the value can be int or string.
>
>
>>> Basically, there are classes of script variables, some accepting dynamic
>>> names (like avps $avp(...), headers $hdr(...), private $var(...) and shared
>>> variables $sht(...) a.s.o.).
>>>
>>> I do not see reason for a special character for certain classes, like avp
>>> or select. It is much much clearer to have:
>>> $avp(name)
>>> $sel(name)
>>>
>>
>> We should use $ only for variables (like any other script language out
>> there). This doesn't mean avps though. The avps should be accessed in
>> some other distinct way. avps are both slow and they consume memory, so
>> their use as script vars should be discouraged.
>>
>>
>>>
>>> rather than:
>>> $name for avps
>>> @name for selects
>>> &name, %name etc. for what so ever variable class
>>>
>>
>> I would use '$' only for fast script vars (that should be declared at
>> the beginning of the script and would be typed), and some function like
>> construct for the other (e.g.  $var=sel("from.uri")).
>>
>
> in shell you can have ${VAR:0:5}. Introducing of PV in openser core started
> from %name used in xlog, but trying to follow shell var syntax.
>
> Besides just nice to discuss, such changes makes no point now. Remember the
> goal is to have a first version for each project that is easy to migrate to
> from older ones. Therefore we committed to go for a best compatibility
> approach. I hope we do not divert from here, otherwise will be come a
> nightmare to get people on board with migration.

Given the amount of time and work it took us to get where we are now,
it's perhaps time to start thinking what comes after you release
Kamailio with sip-router core and this kind of stuff is the next
logical candidate.

Unless Andrei wants to do it, I don't think we are going to release
another standalone SER version, it just makes no sense to maintain two
separate projects with a handful of active people.

I agree that we should not make such changes now, but perhaps after
the next Kamailio release we should put some cleanup (in addition to
merging and adding new stuff) work on our agenda too.

   Jan.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev