[sr-dev] [kemi] porting module functions with input/output PV parameters

[Mititelu Stefan]

>
> 1. What would be the best practice for porting module functions that
> read/write data from/to a pseudo-variable? ...At the moment I'm thinking of
> using str for input and return; probably this will lead to partially
> duplicating the code of the existing module functions.
>
>
> The idea is to no longer pass names of variables to the functions in the
> embedded language, but the string value for it.
>
> The functions that get a variable name to set can have to receive it as
> string, then use pv_cache_get(name) to resolve to the PV strctures. These
> functions will need a wrapper that will call the function in C expecting
> already the PV structure.
>
> Now there is a wrapping system that together with the fixups convert from
> the parameters given as string values in kamailio.cfg to the PV structure.
>
The idea is to no longer pass names of variables to the functions in the
> embedded language, but the string value for it.
>
2. Will kemi support some other types besides int/str/none? (i.e. SR_KEMIP_
> *PV*)
>
> Of course the goal is to extend kemi and make it easier to use for common
> cases. If you have some proposal to make, just open a discussion about it.
>
> The goal is to be able to have very small wrappers for native config
> language and kemi (and in many cases no wrappers) that will call a common C
> functions.
>
> The common C function should accept only int, str* and pv_spec_t* (for
> functions that need to write in a pv) parameters.
>
> The current fixup system for native config converts at some point to
> int/str using fixup_get_ivalue() and fixup_get_svalue().
>

I will also have a look in apy_kemi.c for KSR.pv.get/set methods for a
better understanding. Thanks! :D



If something is not clear regarding kemi, just ask more, I am happy to try
> to clarify better.
>

3. From what I've understood so far, kamailio becomes the interpreter
itself. This actually mean that in the scripts I can do something like this:
"
import myPythonFramework
import otherPythonLib
# play with myPythonFramework
# play with otherPythonLib
"
right?


Thank you
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20170113/9b0fed64/attachment.html>