[sr-dev] Implementation question / usrloc / registrar

[Carsten Bock]

Hi,

thanks for the hint.
I was always about to say, it does not exist but it is simply not documented.
I will take a look at it; thanks!

Thanks,
Carsten

2011/2/8 Daniel-Constantin Mierla <miconda at gmail.com>:
> Hello,
>
> On 2/8/11 11:59 AM, Carsten Bock wrote:
>>
>> Hi everyone,
>>
>> just a short request for comments:
>> Similar to the dialog-variables, which i implemented in my IMS branch
>> recently, i need something similar for usrloc. Basically, i need to
>> store additional data to a registration; which i can access after
>> "lookup()" or upon a "is_registered()" call. Basically:
>>
>> $reg_var(test) = "some value";
>> save();
>> - - -
>> lookup();
>> xlog("reg_var(test) is $reg_var(test)\n");
>>
>> Now there are different approaches:
>> 1) implement this funtionality in usrloc/registrar directly (similar
>> to my dialog-pvar-implementation). The performance when doing this
>> impact should be minor if not used, since simply an empty pointer
>> would be carried along every registration. This would be the cleanest
>> way to do this; but however since many people are using usrloc i have
>> a little respect doing changes on such core-module. Maybe it could be
>> implemented as a change in usrloc and a dedicated module just for
>> getting and setting the values.
>> 2) another way would be to implement this in a dedicated module. This
>> would mean, that i would not touch usrloc module and it would of
>> course have no impact on "regular" usrloc usage at all if not used. I
>> would have to add a second list of in-memory values, which would have
>> to be synched with db, a second timer to do so. The list would be
>> dependent on the usrloc callbacks. There is always the danger
>> data-inconsistency.
>> 3) is there any way, to do this with some event-routes,
>> shared-variables or something similar?
>>
>> Any thoughts?
>> Comments very welcome!
>
> I think that modules_s/usrloc has something like this, maybe looking at it
> can help somehow to get it in k version.
>
> Cheers,
> Daniel
>
>> Kind regards,
>> Carsten
>>
>> P.S.: If i do not receive any comments, i would implement the first
>> approach (directly in usrloc/registrar) in my IMS-branch for later
>> merging into master.
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>



-- 
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany

Mobile +49 179 2021244
Home +49 40 34927217
Büro (Verl) +49 5246 801427
Fax +49 40 34927218
mailto:carsten at bock.info