[OpenSER-Devel] dialog callbacks: mi enhancements

Dan Pascu dan at ag-projects.com
Fri Apr 18 23:21:03 CEST 2008


On Friday 18 April 2008, Ovidiu Sas wrote:
> Hello Dan,
>
> Initially, I created a separate callback for this job, but in the end
> I was just replicating code, and therefore, I merged them.  Maybe we

I do not think this is about replicating or merging code, it's about 
clarity and consistency of the API. You use a callback mechanism that is 
supposed to be used by the modules on top of the dialog module to get 
notifications (i.e. move information from the dialog module into the 
other module), the other way around (to move information from the other 
module into the dialog module). I find that this approach creates a 
confusing interface. Just consider the awkward x_param member that is 
passed to any dialog callback, even if it means nothing to all of them 
except this new callback.

> can create two wrappers around the generic dialog callback:
>  - one would be the existing run_dlg_callback (and keep the existing
> signature), - the other one would be run_mi_callback.

Again, I do not see these just as the same thing. I see them as 2 
different interfaces. The existing one and a new one to move information 
the other way around.
They may look the same because one will most likely implement this new 
interface using a callback mechanism too, but the distinction of which 
interface moves data in which direction is important IMO.

>
> Once again Dan, thank you for your time.
>
> Also, I would like to hear other opinions with respect to this issue.
> Bogdan, Henning?
>
> Another thing that I would like to know, what would the users prefer:
> a separate mi command for listing the extra information from all the
> modules sitting on top of the dialog module, or by default list all
> the available data?

I think the dialog module should list all the available data under a 
single command. Otherwise I see no point to this whole thing; you could 
implement a function to extract the context from the dialog module (the 
thing that you are missing right now in your module) and implement a MI 
command in each such module.

> I would prefer to list everything under the existing mi dlg_list
> command, but that's just me ...


-- 
Dan



More information about the Devel mailing list