13 Jan
2017
13 Jan
'17
7:30 p.m.
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