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

[Henning Westerholt]

On Monday 17 December 2007, Dan Pascu wrote:
> > yes, this is an idea that was discussed for some time, but without any
> > clear results for implementation. It is a bit complex and we need to
> > think it over and over to be sure we get it right. Let's not jump into
> > action until everything is settled.
> >
> > Give me couple of days to go over this idea again and to dig for any
> > previous notes on this matter.

Hi Bogdan, Hi Dan,

sure, no problem.

> > The first thing we need to clarify is how to pass an unlimited number
> > of parameters:
> >     - via array, like main() does - but it might be too generic for our
> > purposes
> >     - combination of fixed and additional parameters. The function will
> > have the 2 fix params and any additional params will be passed as array
> > - this will maintain some clarity (we still have the visible
> > parameters), but also scalability.

If we go with the combination, i would suggest using only one fixed parameter, 
as most modules functions are defined like this at the moment.

> I think there's another way. Practically speaking we do not need
> an "unlimited" number or parameters (whatever that means on hardware that
> is limited by nature). I do not expect anyone to export module functions
> that need more than 5-7 parameters and if someone does I don't think we
> want to have such functions available (just think what it means to
> remember how to call a function with that many parameters).

This limitation makes sense of course, i suggested the same.

> What we can do is to use the standard C vararg mechanism to pass multiple
> args. The script parser will impose a limit on how many arguments a
> function can have (say 5-10). It will parse the script and build those
> parameters from the function calls. Will fill the remaining unspecified
> ones with NULL and call a function passing all those arguments.

Then we have a overhead of 5-10 x 32 bits on the stack for each function call, 
because the space for each parameter is reserved, even its NULL. This is the 
way this mechanism work, unfortunally. 

> Then the module can define functions using the ellipsis notation to
> indicate they are prepared to accept a variable number of arguments.
>
> A function with no arguments will be declared like:
>
> static int function(struct sip_msg *msg, ...);
> One that accepts 1 argument:
> static int function(struct sip_msg *msg, char *arg1, ...);
>
> and so on.

Ok, then the module function implementation would look like this:

function(struct sip_msg *msg, ...){
  va_list ap;
  va_start(ap, msg);
  char * param, op_param1, op_param2;

  param = va_arg(ap, char*);
  if(param)
    op_param1 = param;
  param = va_arg(ap, char*);
  if(param)
    op_param2 = param;

  va_end(ap);

  // do some work with optional params
  bla(param1);
  blub(param2);
  // do some other work
}


The module function implementation according to our proposal would be:

function(struct sip_msg *msg, unsigned int count, char** params){
  // do some work with optional params
  if (count > 0)
    bla(params[0]);
  if (count > 1)
    blub(params[1]);
  // do some other work
}

I think this option is much more cleaner and understandable.

Cheers,

Henning