[sr-dev] K|S usrloc merge

[Daniel-Constantin Mierla]

Hello,

On 2/1/12 11:50 AM, Jason Penton wrote:
> Daniel, you will probably be most interested in this based on 
> yesterday's dev chat....
>
> Following the discussion from the dev irc yesterday re. usrloc 
> requirements:
>
> To summarise the functionality required for GRUU - unique id (for you) 
> and custom subscriber data (for us). As you mentioned yesterday, S 
> version of usrloc has this particular functionality. After a brief 
> look at S-version of usrloc this morning, I have to say I prefer it. 
> Mainly because of the way it handles urecords and ucontacts 
> separately. In K-version - a urecord structure really only exists if 
> there is a contact. There are more deadly implications when in DB mode 
> where a static urecord structure is built on demand. IMHO, I think we 
> should use S module as the basis of a merge?
>
> I'd be interested in yours/other interested members' input.
I haven't looked at specific implementations, just some overview to see 
what missing features are in one or the other. I think k version of 
usrloc/registrar pair has more on db modes and record matching (call-id, 
etc...), branch flags, callbacks for pua_usrloc, $ulc(...) 
pseduo-variable class. s version has a uid, per contact attributes, 
sip-instance support and implements DB2 API which unfortunately not 
implemented across all db connectors, thus limiting the backends. So the 
merge should preserve the functionalities from both, looks like going to 
be a bit of effort to do it. If you want to start, I may help, 
eventually contributing some parts or during the design process. 
Starting from one or the other, is a matter of developer preference -- 
can be started from scratch, like usrloc-ng :-), taking from each of 
existing "only the good parts".

Cheers,
Daniel

> -- 
> Daniel-Constantin Mierla -- http://www.asipto.com
> http://linkedin.com/in/miconda -- http://twitter.com/miconda