[Kamailio-Devel] [Kamailio-Users] RFC: branches/location records control

[Daniel-Constantin Mierla]

On 08/22/08 12:09, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 08/22/08 10:42, Juha Heinanen wrote:
>   
>> Daniel-Constantin Mierla writes:
>>
>>  > does an AVP being a data structure solve this (if I understood properly 
>>  > the issue)? 
>>
>> daniel,
>>
>> currently when contacts are loaded, branch info is stored in a PV and i
>> have had to hack that by encoding the multiple pieces of branch info
>> into a single string valued PV.  thus yes, things would have been
>> simpler if an avp could be a data structure (record with fields) as you
>> suggest:
>>
>>  > $avp(d:xbranch=>uri)
>>  > $avp(d:xbranch=>dst_uri)
>>  > ...
>>  > 
>>  > xbranch is the name of the avp, uri and dst_uri are inner attributes.
>>
>> makes sense.
>>
>>  > Perhaps $avp(d:xbranch) should return a string with comma separated list 
>>  > of serialized attributes.
>>
>> i don't see that kind of function very useful except for debug purpose.
>> what is important is that the fields of avp record can be accessed
>> individually.
>>   
>>     
> This might be good for storing/loading structures from database. Or 
> maybe another format is more advisable.
>
>   
>> regarding loading and consuming branched for the purpose of serial
>> forking, it would be still better if no copying of branch info into an
>> avp would not needed at all like i suggested here:
>>
>>   the more i think about this, more convinced i get that serial forking
>>   should be integrated in tm module, i.e., each time when t_relay is
>>   called (perhaps with a new "serial fork" parameter), it would serve the
>>   next set of branches that have the highest q value and then mark those
>>   as served in dset.c branches array.  that way all the info would be
>>   always present in branches array and there would be no need to
>>   save/clear/restore branches.
>>   
>>     
> You are right. Looks like we need to re-think a bit all this serial 
> forking in tm. Should be added to the proposals for v2.0.
>   
just to clarify, by v2.0 I meant the NG version, where we look also to 
asynchronous processing, a.s.o. -- discussion was already started. If 
comes handy, could get into before.

Cheers,
Daniel

> Cheers,
> Daniel
>
>
>   
>> -- juha
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>
>>   
>>     
>
>   

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