<p>Hi Timo,</p>
<p> this wont be available to configuration users but to other modules through API. </p>
<p>On phone now so will respond to use cases when I'm back at my PC</p>
<div class="gmail_quote">On Aug 12, 2011 12:48 PM, "Timo Reimann" <<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>> wrote:<br type="attribution">> Hey,<br>> <br>> <br>> On 12.08.2011 12:33, Jason Penton wrote:<br>
>> We are currently refactoring and cleaning the various IMS modules for<br>>> inclusion into SR, diameter_rx, diameter_cxdx, diameter_ro, etc.<br>>> <br>>> One thing we have noticed is that the use of dialog module functions<br>
>> would make the code alot better and cleaner, so 2 questions:<br>>> <br>>> 1. why is the Dialog module not exposing more if its methods?<br>>> 2. Can we put in a patch to expose the ones we require.<br>
>> <br>>> Currently, we have exposed and are using the following:<br>>> <br>>> lookup_dlg;<br>>> terminate_dlg;<br>>> get_dlg;<br>>> unref_dlg;<br>>> ref_dlg;<br>> <br>> I strongly opt against exporting any functions related to reference<br>
> management. It's already hard to handle reference counting properly<br>> inside the module; allowing configuration users to touch that part of<br>> the module will likely result in all kinds of ugly bugs. IMHO, it's best<br>
> to keep it internal and provide functions to whatever feature you like.<br>> There's already a bunch of dialog PVs and (more recently) the very<br>> generic dialog variable mechanism which allows you to do a series of things.<br>
> <br>> Regarding the other functions you mentioned, can you outline what your<br>> use case for those is?<br>> <br>> <br>> Cheers,<br>> <br>> --Timo<br>> <br>> _______________________________________________<br>
> sr-dev mailing list<br>> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div>