[Devel] avpops updates

Daniel-Constantin Mierla daniel at voice-system.ro
Sat Feb 11 14:27:03 CET 2006


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 $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 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



More information about the Devel mailing list