[OpenSER-Devel] Request for comment: module interface extension

[Dan Pascu]

On Monday 17 December 2007, Henning Westerholt wrote:
> On Monday 17 December 2007, Dan Pascu wrote:
> > > So for now i suggest only to change the module functions export to:
> > >
> > > typedef int (*cmd_function)(struct sip_msg*, int count, char
> > > **params);
> >
> > I do not like this model too much. All arguments are hidden inside an
> > array, from where the function must take and assign them to
> > variables. No clear function prototype can be defined by this model
> > and calling functions exported by other modules will become complex
> > and awkward.
>
> Hi Dan,
>
> well, sure there is some sort of information hiding in this array. But
> to define more prototypes like this:
>
> typedef int (*cmd_function)(struct sip_msg*, char *param1, char*
> param2, ... char* paramN);
>
> is also not optimal. Here happens also some sort of information hiding,
> the actually used variables vs. the boilerplate code.. And the current
> interface with char* that gets casted around to fit to arbitrary
> variables is also not really clean..

While not optimal, is far less disruptive that what you propose. At least 
I can give my function parameters meaningful names and have an idea of 
what the function receives and what expects. With the array you propose I 
have no clue unless I inspect the inner code.

>
> In regards to the second point you've raised, the intermodule function
> calls:
>
> Modules that holds functions that needs to be used from outside should
> export a clean API struct with a 'bind' function, like the tm or auth
> modules, in my opinion. No modules should call functions that are only
> exported via the config script. This is not type safe at all. And the
> module functions exported with this type of API don't need to adhere to
> the interface of the config script.

Sometimes that's not an option as the same function is made available to 
the script and used from other modules as well. In your model this means 
we have to define a function and a wrapper because we have to export the 
same function under 2 different calling conventions.


Regarding this change, C already has a mechanism to indicate that a 
function can receive a variable number of arguments, by using the 
ellipsis notation and varags. Why not use that which will allow to have 
functions with as many arguments you want without the awkwardness of 
passing arrays for arguments. All the function modules have to do is to 
declare themselves as accepting a variable number of arguments even 
though they do not actually need to parse and use those extra arguments.
And the script parser will pass as many arguments to the function as it 
has received from the script.
This even has the advantage that we no longer have to define multiple 
prototypes in the module's cmd_export_t structure if we have a function 
with optional arguments. The function is declared only once with a 
prototype including the minimum required arguments and the rest will be 
determined at runtime if present using varargs.

-- 
Dan