[sr-dev] Exposing additional dialog functions through API

[Timo Reimann]

Hey Jason,


On 12.08.2011 12:54, Jason Penton wrote:
> this wont be available to configuration users but to other modules
> through API.

Ok, thanks for clarifying this. Still, allowing other modules to fiddle
with referencing counting is a no-go IMHO.


> On phone now so will respond to use cases when I'm back at my PC

Sounds good!


Cheers,

--Timo



> On Aug 12, 2011 12:48 PM, "Timo Reimann" <timo.reimann at 1und1.de
> <mailto:timo.reimann at 1und1.de>> wrote:
>> Hey,
>>
>>
>> On 12.08.2011 12:33, Jason Penton wrote:
>>> We are currently refactoring and cleaning the various IMS modules for
>>> inclusion into SR, diameter_rx, diameter_cxdx, diameter_ro, etc.
>>>
>>> One thing we have noticed is that the use of dialog module functions
>>> would make the code alot better and cleaner, so 2 questions:
>>>
>>> 1. why is the Dialog module not exposing more if its methods?
>>> 2. Can we put in a patch to expose the ones we require.
>>>
>>> Currently, we have exposed and are using the following:
>>>
>>> lookup_dlg;
>>> terminate_dlg;
>>> get_dlg;
>>> unref_dlg;
>>> ref_dlg;
>>
>> I strongly opt against exporting any functions related to reference
>> management. It's already hard to handle reference counting properly
>> inside the module; allowing configuration users to touch that part of
>> the module will likely result in all kinds of ugly bugs. IMHO, it's best
>> to keep it internal and provide functions to whatever feature you like.
>> There's already a bunch of dialog PVs and (more recently) the very
>> generic dialog variable mechanism which allows you to do a series of
> things.
>>
>> Regarding the other functions you mentioned, can you outline what your
>> use case for those is?
>>
>>
>> Cheers,
>>
>> --Timo