[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