3 Jul
2009
3 Jul
'09
12:15 p.m.
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
3 Jul
3 Jul
12:26 p.m.
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/
12:36 p.m.
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
12:45 p.m.
On 07/03/2009 06:36 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Daniel-Constantin Mierla writes:
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
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
1:02 p.m.
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 07/03/2009 06:36 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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. 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 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
1:25 p.m.
On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
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/
On Jul 03, 2009 at 18:45, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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.
On 07/03/2009 06:36 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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.
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 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.
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")).
14 Jul
14 Jul
10:14 a.m.
On Fri, Jul 3, 2009 at 7:25 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
On 07/03/2009 07:02 PM, Andrei Pelinescu-Onciul wrote:
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 Jul 03, 2009 at 18:45, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
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.
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.
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")).
9:54 a.m.
On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
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).
whose confusion?
like the discussion on
lookup_domain function revealed, it is confusing
that the same prefix ($ char) is used for two different things.
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.
10:10 a.m.
On 14.07.2009 15:54 Uhr, Jan Janak wrote:
On Fri, Jul 3, 2009 at 6:45 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
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.
whose confusion?
like the discussion on
lookup_domain function revealed, it is confusing
that the same prefix ($ char) is used for two different things.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3 Jul
3 Jul
12:38 p.m.
On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
On 07/03/2009 06:15 PM, Juha Heinanen wrote:
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.
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.
1:04 p.m.
On 07/03/2009 06:38 PM, Jan Janak wrote:
On Fri, Jul 3, 2009 at 6:26 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
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
On 07/03/2009 06:15 PM, Juha Heinanen wrote:
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.
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.
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/
12:29 p.m.
On Fri, Jul 3, 2009 at 6:15 PM, Juha Heinanen<jh(a)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.
5654
days inactive
5665
days old
11 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com