[sr-dev] RFC: deprecating add_contact_alias()

Daniel-Constantin Mierla miconda at gmail.com
Tue Oct 14 17:53:15 CEST 2014


On 14/10/14 17:44, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> If there is a strong desire to keep add_contact_alias(), it should be
>> kept after all, but properly documented that has the limitations on
>> making new contact visible and should not be used in a sip server
>> instance used for presence, dialog, ...
> i have made enhancements to a large number of functions and never
> created new ones unless there has been backwards incompatible change in
> parameters or performance penalty.
Actually there were quite big implications in other modules (like in 
dialog done initially and then in tm module done recently to get it all 
work like a replacement for fix_natted_contact()) -- so it was not just 
about a new (or replacement) function in nathelper module.

>
> if there has not been either in case of set_contact_alias, it should not
> have not created in the first place and therefore i'm against
> deprecating add_contact_alias.
It's fine to keep add_contact_alias() from my point of view, if you feel 
it performs better for your needs (I didn't start this discussion after 
all), but docs have to list the limitations.
>> Or, even better in my opinion at this time, just point both to same C
>> function. Overall, as this is discussion about deprecating something, it
>> will happen more recently with the future next major release, 4.3.
> i didn't get answer to performance issue.  is there penalty when changes
> are applied to the message by set_contact_alias function? if yes, then
> add_contact_alias code should not be changed.
I did say something about performances from my point of view in the 
previous email.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-dev mailing list