[OpenSER-Devel] pvap fixup to mod_fix.c?

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Dec 17 16:14:42 UTC 2007


Hi Henning,

IMHO, the current approach for fixup-ing the params is good and I see no 
reason the change it. The point Juha brought in discussion was about 
complex functions where there are different types of params.

But I see the following solution:

- let's say we have all the generic fixup function made for param 1 (or 
no index). So, we have :
       fixup_regexp(void**param);
       fixup_int(void**param)
       fixup_str(void**param)
       fixup_pv(void**param)

- and the function fixup will be something like:
    my_fixup(int index, void**param) {
        switch (index) {
          case 1:
             fixup_regexp(param);
                          break;
          case 2:
             fixup_pv(param)
                          break;
        }  
    }  

What do you think about this?

Regards,
Bogdan

Henning Westerholt wrote:
> On Monday 17 December 2007, Juha Heinanen wrote:
>   
>> Daniel-Constantin Mierla writes:
>>  > indeed, moving that will do quite a lot of cleanup in modules, making
>>  > easier to maintain in case of a change. I am for this migration.
>>
>> if one function has one pvar arg and another one has two, should there
>> then be pvar1 fixup and pvar2 fixup in the library or just one that has
>> a test for both param_no 1 and param_no 2?
>>
>> to me it would be cleaner if each argument would have its own fixup
>> function.  now that henning is going to introduce a loop into arg
>> processing, could there be a loop also for fixup processing?
>>     
>
> Sure, this would be cleaner. But how do should this implemented? Perhaps like 
> this:
>
> static cmd_export_t cmds[] = {
> {"acc_log_request", w_acc_log_request, 1, acc_fixup_1, acc_fixup_2, ..., 
> acc_fixup_N, free_acc_fixup, REQUEST_ROUTE|FAILURE_ROUTE}, ...}
>
> but this interface not really pretty. Usage of a struct for functions params 
> and the belonging fixup functions would be possible, but this is even more 
> complicated than the proposed char** array. 
>
> Cheers,
>
> Henning
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>
>   




More information about the Devel mailing list