Hello,
the avpops module was refurbished to benefit better of pseudo-variables. In addition, the avp and hdr pseudo-variables can have dynamic names. Here are some details:
- all parameters being avp names in avpops functions MUST be specified in the same format as pseudo-variables: - $avp(i:23) - refers to the avp having the integer id 23 - $avp(s:test) - refers to the avp having the name 'test' - $avp($aliasid) - refers to the avp defined by avp alias 'aliasid' - example: avp_write("i:10", "$avp(i:30)") - write integer value 10 into the avp having the id 30
- avps and hdrs pseudo-variables can have dynamic names: -$avp($pvar) refers to the avp having the name the value of $pvar -$hdr($pvar) refers to the hdr having the name the value of $pvar - please note that the pseudo-variables specifiers have priority over avp aliases (if you define an avp alias $ru, $avp(ru) will refer to the avp having the name the value of R-URI)
- in all parameters of avpops module can be used pseudo-variables where are expected values - avp_check("$fd", "eq/$td") returns true if the domain of From uri is the same with domain part of To uri - avp_write("$tU", "$avp($fU)") - writes the username in To header in the avp having the name the username from From header
- avp_pushto() - cannot add anymore headers - same functionality is provided by the textops module via append_hf() and append_to_reply() functions - the format of the first parameter of avp_pushto() follows the pseudo-variables names as well. - avp_pushto("$ru[/username|domain]", "...") to rewrite parts of R-URI - avp_pushto("$du", "...") to rewrite dst_uri
- for developers, internal structure int_str has changed from (int, str*) to (int,str) to avoid extra reference
- the documentation will be updated soon (module readme and avpops tutorial)
Still to come: - support for global avps: avps shared between all processes during the openser lifetime - support for script avps: avps specific per process with life time only during the script execution (temporary avps, which do not need to last too much, using private memory) - support for local avps: avps specific per process kept during openser lifetime (avps which need to be kept for each process, without synchronized access, using private memory) - avp_db_query() - ability to send a raw query (simple, joins, unions ...) to database and load the result in avps (e.g., avp_db_query("select first_name, last_name from subscriber where username='$tU' and domain='$td'", "$avp(first_name);$avp(last_name)"))
Testing and feedback are more than welcome.
Cheers, Daniel
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
- $avp($aliasid) - refers to the avp defined by avp alias 'aliasid' -$avp($pvar) refers to the avp having the name the value of $pvar
These 2 seem to conflict with each other. They look exactly the same but claim to yield different results. The first is a direct access of the value of the alias, while the second is an indirect access of the value of the avp which's name is taken from $pvar. This is _very_ confusing.
The problem comes from the fact that avp aliases and pseudo variables use the same notation but are handled so differently by $avp().
I think the best way to address this is to solve the issue at its source.
What I have in mind is to use $something for pseudo variables like before but unify the avp and avp alias notation, since an avp alias is just another name for an existing avp. Thus we can have these:
$avp(i:nnn) - integer avp $avp(s:some_name) - string avp with name 'some_name' $avp(some_name) - if some_name is defined as an avp alias, use the avp pointed by that alias, else lookup the string avp with the name 'some_name'
In short, anything not having a i: or s: in front of it should be first looked up as an avp alias, but if that alias is not defined it should be considered as the name of the string avp.
This will make avp aliases have priority over string aliases, but I think that's fine. And this is much more clear (both by eliminating the confusion with pseudo variables and by unifying aliases with avps notation wise). Backward compatibility is preserved, in the sense that if some_name is not defined as an alias it's still looked up as an string avp as it was before.
I haven't mentioned this directly and to avoid any misunderstanding, my suggestion means that $ will no longer be used to identify an avp alias.
On Saturday 11 February 2006 00:09, Dan Pascu wrote:
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote: What I have in mind is to use $something for pseudo variables like before but unify the avp and avp alias notation, since an avp alias is just another name for an existing avp. Thus we can have these:
$avp(i:nnn) - integer avp $avp(s:some_name) - string avp with name 'some_name' $avp(some_name) - if some_name is defined as an avp alias, use the avp pointed by that alias, else lookup the string avp with the name 'some_name'
In short, anything not having a i: or s: in front of it should be first looked up as an avp alias, but if that alias is not defined it should be considered as the name of the string avp.
On 02/11/06 00:09, Dan Pascu wrote:
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
- $avp($aliasid) - refers to the avp defined by avp alias 'aliasid' -$avp($pvar) refers to the avp having the name the value of $pvarThese 2 seem to conflict with each other. They look exactly the same but claim to yield different results. The first is a direct access of the value of the alias, while the second is an indirect access of the value of the avp which's name is taken from $pvar. This is _very_ confusing.
The problem comes from the fact that avp aliases and pseudo variables use the same notation but are handled so differently by $avp().
I think the best way to address this is to solve the issue at its source.
What I have in mind is to use $something for pseudo variables like before but unify the avp and avp alias notation, since an avp alias is just another name for an existing avp. Thus we can have these:
$avp(i:nnn) - integer avp $avp(s:some_name) - string avp with name 'some_name' $avp(some_name) - if some_name is defined as an avp alias, use the avp pointed by that alias, else lookup the string avp with the name 'some_name'
In short, anything not having a i: or s: in front of it should be first looked up as an avp alias, but if that alias is not defined it should be considered as the name of the string avp.
This will make avp aliases have priority over string aliases, but I think that's fine. And this is much more clear (both by eliminating the confusion with pseudo variables and by unifying aliases with avps notation wise). Backward compatibility is preserved, in the sense that if some_name is not defined as an alias it's still looked up as an string avp as it was before.
I would like to have a clear notation for avp aliases as well and your solution seems good. I was considering the notation from existing pseudo-variables. Maybe it would be better to force "i:number" and "s:string" also for values, to avoid other confusions.
Is there any other opinion for this issue?
Cheers, Daniel
On Saturday 11 February 2006 15:27, Daniel-Constantin Mierla wrote:
I would like to have a clear notation for avp aliases as well and your solution seems good. I was considering the notation from existing pseudo-variables. Maybe it would be better to force "i:number" and "s:string" also for values, to avoid other confusions.
I think that enforcing i: and s: for values is not necessary. You know from the context that you handle a value so there isn't any confusion as with pseudo variables versus aliases. And to have all strings (which are used most) prefixed with s: may soon become annoying. I think that a value without any prefix should be considered a string value by default as it is now.
If we have these notations I think any confusion will be eliminated:
Pseudo variables (start with $): $something - pseudo variable
AVPs (in the form $avp(xxx)): $avp(i:something) - integer avp $avp(s:something) - string avp $avp(something) - avp alias if defined else string avp
Values (in the form "xxx"): "i:something" - integer value "s:something" - string value "something" - string value
They seem pretty consistent and confusion-free to me in this form.
Is there any other opinion for this issue?
Cheers, Daniel
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
- avps and hdrs pseudo-variables can have dynamic names: -$avp($pvar) refers to the avp having the name the value of $pvar -$hdr($pvar) refers to the hdr having the name the value of $pvar
It's not clear from this description, but can we now have something like $avp($avp(s:myavp)) or $hdr($avp(i:615)) or is this limited to pseudo variables?
For example would this work?
avp_write("foo", "$avp(s:myavp)"); avp_write("777", "$avp(s:foo)");
now would $avp($avp(s:myavp)) yield 777 ?
On 02/11/06 00:14, Dan Pascu wrote:
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
- avps and hdrs pseudo-variables can have dynamic names: -$avp($pvar) refers to the avp having the name the value of $pvar -$hdr($pvar) refers to the hdr having the name the value of $pvar
It's not clear from this description, but can we now have something like $avp($avp(s:myavp)) or $hdr($avp(i:615)) or is this limited to pseudo variables?
For example would this work?
avp_write("foo", "$avp(s:myavp)"); avp_write("777", "$avp(s:foo)");
yes, it should work, Actually, avps can be considered parts of pseudo-variables (writable), they are listed in the pseudo-variables tutorial.
now would $avp($avp(s:myavp)) yield 777 ?
yes, if not, it is a bug somewhere ...
Cheers, Daniel
On Saturday 11 February 2006 15:29, Daniel-Constantin Mierla wrote:
On 02/11/06 00:14, Dan Pascu wrote:
On Friday 10 February 2006 21:44, Daniel-Constantin Mierla wrote:
- avps and hdrs pseudo-variables can have dynamic names: -$avp($pvar) refers to the avp having the name the value of
$pvar -$hdr($pvar) refers to the hdr having the name the value of $pvar
It's not clear from this description, but can we now have something like $avp($avp(s:myavp)) or $hdr($avp(i:615)) or is this limited to pseudo variables?
For example would this work?
avp_write("foo", "$avp(s:myavp)"); avp_write("777", "$avp(s:foo)");
yes, it should work, Actually, avps can be considered parts of pseudo-variables (writable), they are listed in the pseudo-variables tutorial.
now would $avp($avp(s:myavp)) yield 777 ?
yes, if not, it is a bug somewhere ...
How many levels can this go? Or is it only limited to 1 indirection?
$avp($avp($avp(...)))
The documentation for avpops module was updated to reflect the latest changes and published online at:
http://openser.org/docs/modules/1.1.x/avpops.html
Cheers, Daniel
On 02/10/06 21:44, Daniel-Constantin Mierla wrote:
Hello,
the avpops module was refurbished to benefit better of pseudo-variables. In addition, the avp and hdr pseudo-variables can have dynamic names. Here are some details:
- all parameters being avp names in avpops functions MUST be specified
in the same format as pseudo-variables: - $avp(i:23) - refers to the avp having the integer id 23
- $avp(s:test) - refers to the avp having the name 'test'
- $avp($aliasid) - refers to the avp defined by avp alias 'aliasid'
- example: avp_write("i:10", "$avp(i:30)") - write integer value 10
into the avp having the id 30
- avps and hdrs pseudo-variables can have dynamic names: -$avp($pvar) refers to the avp having the name the value of $pvar -$hdr($pvar) refers to the hdr having the name the value of $pvar
- please note that the pseudo-variables specifiers have priority
over avp aliases (if you define an avp alias $ru, $avp(ru) will refer to the avp having the name the value of R-URI)
- in all parameters of avpops module can be used pseudo-variables
where are expected values
- avp_check("$fd", "eq/$td") returns true if the domain of From uri
is the same with domain part of To uri
- avp_write("$tU", "$avp($fU)") - writes the username in To header
in the avp having the name the username from From header
- avp_pushto() - cannot add anymore headers - same functionality is
provided by the textops module via append_hf() and append_to_reply() functions
- the format of the first parameter of avp_pushto() follows the
pseudo-variables names as well.
avp_pushto("$ru[/username|domain]", "...") to rewrite parts of R-URI
avp_pushto("$du", "...") to rewrite dst_uri
for developers, internal structure int_str has changed from (int,
str*) to (int,str) to avoid extra reference
- the documentation will be updated soon (module readme and avpops
tutorial)
Still to come:
- support for global avps: avps shared between all processes during
the openser lifetime
- support for script avps: avps specific per process with life time
only during the script execution (temporary avps, which do not need to last too much, using private memory)
- support for local avps: avps specific per process kept during
openser lifetime (avps which need to be kept for each process, without synchronized access, using private memory)
- avp_db_query() - ability to send a raw query (simple, joins, unions
...) to database and load the result in avps (e.g., avp_db_query("select first_name, last_name from subscriber where username='$tU' and domain='$td'", "$avp(first_name);$avp(last_name)"))
Testing and feedback are more than welcome.
Cheers, Daniel
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
-
Dan Pascu -
Daniel-Constantin Mierla