> > 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
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
