@mshary pushed 1 commit.

33f6d72929228bd1e1ebb7b35608e9b530b6c346 Merge branch 'kamailio:master' into master

The implementation looks ok to me since it is convenient for now to keep changes to the regular cmd export functions low.

The force-pushed appeared because of reverting some merge commit and then changing the commit message.

I think this is ok for a merge.

In my opinion, it does not look right. The kamailio.cfg wrapper function should call the kemi function, not the other way around.

If it is not an out put script variable, then the parameter should not be provided as kamailio.cfg pseudo-variable name, but as corresponding value. Practically, the example above with:

``` KSR.carrierroute.cr_user_carrier("$fU", "$fd", ... ```

Should be:

``` KSR.carrierroute.cr_user_carrier(KSR.kx.get_fuser(), KSR.kx.get_fhost(), ...) ```

Also, looking a bit at the code of the commit, for example:

``` int ki_cr_user_carrier(struct sip_msg * _msg, str *_user, str *_domain, str *_dstavp) {

// native api already checks if any of required argument is null // so this is not strictly necessary. if (!_msg || !_user || !_domain || !_dstavp) { LM_ERR("missing a required parameter\n"); return -1; };

return w_cr_load_user_carrier(_msg, _user->s, _domain->s, _dstavp->s); } ```

The content pointed by `_user->s` is `"$fU"` (considering the example given in the comment above), and inside `w_cr_load_user_carrier()`:

``` int w_cr_load_user_carrier(struct sip_msg * _msg, char *_user, char *_domain, char *_dstavp) { gparam_t *pv_user, *pv_domain, *pv_dstavp;

if (_user == NULL) { LM_ERR("cannot get the user parameter\n"); return -1; } else { pv_user = (gparam_t*)_user; if (cr_load_user_carrier_fixup((void**)&pv_user, 1) != 0) { LM_ERR("cannot parse the user parameter\n"); return -1; } } ... ```

It is doing fixup (a little bit odd way), but then no free fixup.

Anyhow, this is not the proper way kemi is supposed to work, from the kemi script it should come direct string (or integer) values, not names of Kamailio-specific pseudo-variables.

I am bit lost on how the code execution flow works for KEMI. My understanding was that all KEMI methods are exported by `sr_kemi_t` structure array, which specifies exported function names, their internal implementation function name and its arguments either as string `SR_KEMIP_STR` or integer `SR_KEMIP_INT`.

Each exported function (e.g. `cr_route`) calls internal implementation function (e.g. `ki_cr_route5`), which then checks arguments and then either do the actual implementation or calls up a wrapper function (e.g. `w_cr_do_route`) which does some formatting on input arguments (e.g. `cr_route_fixup`) and then pass it to an existing implementation (e.g. `cr_do_route`). The output arguments control flow is in the opposite direction. Also since there is no free fixup in existing implementation of `cmd_export_t`, so I didn't created or called-in any for KEMI.

``` static cmd_export_t cmds[]={ {"cr_user_carrier", (cmd_function)cr_load_user_carrier, 3, cr_load_user_carrier_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_route", (cmd_function)cr_route5, 5, cr_route_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_route", (cmd_function)cr_route, 6, cr_route_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_nofallback_route",(cmd_function)cr_nofallback_route5, 5, cr_route_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_nofallback_route",(cmd_function)cr_nofallback_route, 6, cr_route_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {"cr_next_domain", (cmd_function)cr_load_next_domain, 6, cr_load_next_domain_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE }, {0, 0, 0, 0, 0, 0} }; ```

On the python side, my example just shows that whatever we pass as argument (whether `$fU` or `KSR.kx.get_fuser()` or `"any-string-value"`), the module function will accept and take care of it (i.e. fetch the actual string value internally), this is already tested in my lab environment.

However, @miconda has suggested the completely different approach. Can you please point me to any existing howto or explain a bit more on how to write KEMI implementation of an existing module function? The example you provide at,

https://github.com/kamailio/kamailio/blob/master/src/modules/posops/posops_m...

is very confusing and does not give any hints on how the flow actually works.

Thank you.

@mshary: commenting on your statement:

On the python side, my example just shows that whatever we pass as argument (whether $fU or KSR.kx.get_fuser() or "any-string-value"), the module function will accept and take care of it (i.e. fetch the actual string value internally), this is already tested in my lab environment.

The issue is you try to leverage variables specific for kamailio.cfg-language inside another programming language, going via kamailio.cfg fixup-mechanism, which is usually done only at startup to optimize for runtime and many of them allocate memory, which has to be freed every time if used repeatedly.

It is also some performance penalty to parse every time the parameter for kamailio.cfg variables, evaluate them, build the evaluated parameter value, use it and the free. Case by case, this could be desired, but it should not be the common approach.

Further more, some scripting languages use similar notation with `$name` for variables, like Ruby, and the functions exported by KEMI must to conflict with them -- like in the next basic example (taken from the internet, not showing a kemi function, but trying to make the point):

``` #!/usr/bin/ruby

$ru = 10 class Class1 def print_global puts "Global variable in Class1 is #$ru" end end ```

Hoping that makes more sense what I tried to explain.

Worth to add that I haven't done any test, only ensured it compiles.

@mshary pushed 0 commits.