[sr-dev] [RFC] Patches ready for merge

Daniel-Constantin Mierla miconda at gmail.com
Tue Mar 8 15:03:57 CET 2011



On 3/8/11 12:05 PM, Alex Hermann wrote:
> On Tuesday 08 March 2011, Daniel-Constantin Mierla wrote:
>> thanks for your contributions.
>>
>> My only question is related to the update to allow_trusted(). Now it
>> goes through all the records, if I understood it right, while the former
>> version was returning at the first match.
> Correct. But only through the records of the matching hash table bucket.
>
>> Maybe we can have a parameter
>> to the function to control this behavior, default the backward
>> compatible way (not to get unexpected behavior due to this change), and
>> when a specific parameter value is given then have the behavior you
>> added. What do you think?
> I thought about adding a parameter, but then i considered the current
> behaviour as buggy, because you can't see if there are multiple matches and
> you don't know which of the matching tags is returned.
>
> For most configurations, the behaviour is backwards compatible, the return
> value is still positive if there is a match, and the tag is still added to the
> avp. The order of added tags was already undefined when there were multiple
> matches, it was undefined which tag would have been added to the avp. Now you
> get them all.
>
> Nevertheless, adding the parameter was a no-brainer...
Thanks Alex,
indeed it was not something complex, it is why I thought it worth doing. 
However,my idea was slightly different to use a parameter for 
allow_trusted(), so you can have many calls of the function with 
different behaviour. But probably makes no sense in this case at it is a 
single list of records to work with. The allow_address() can have 
different groups of addresses, there the multiple match can happen on 
network addresses -- it is not the case anyhow, different function.

Cheers,
Daniel




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




More information about the sr-dev mailing list