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
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 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
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
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla miconda@gmail.com 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
On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla miconda@gmail.com 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
On Fri, Jul 3, 2009 at 7:25 PM, Daniel-Constantin Mierlamiconda@gmail.com wrote:
On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla miconda@gmail.com 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.
On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin Mierlamiconda@gmail.com 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.
On 14.07.2009 15:54 Uhr, Jan Janak wrote:
On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin Mierlamiconda@gmail.com 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 sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin Mierlamiconda@gmail.com 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.
On 07/03/2009 06:38 PM, Jan Janak wrote:
On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin Mierlamiconda@gmail.com 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.
On Fri, Jul 3, 2009 at 6:15 PM, Juha Heinanenjh@tutpro.com 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.
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com