Re: [sr-dev] [kemi] porting module functions with input/output PV parameters
On 13/01/2017 17:30, Mititelu Stefan wrote: > >> 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 Note that the KSR.pv and KSR.x submodules are the only ones implemented in the interpreter modules at this moment. All the other submodules are not tied to the interpreter modules. Probably the KSR.pv will get out of interpreter, the KSR.x is intended to be interpreter-specific extensions (right now is exporting the function to execute any kind of kamailio.cfg function exported by its modules and the implementation of an "exit" equivalent in the embedded languages -- Lua has an exit, but that does a kill of the interpreter and by that, of kamailio). > > > > 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? Yes, you can import any Python lib/framwork available outside there, with no relation to Kamailio, and combine it with the KSR to build whatever python script you need. As a side remark, I am not a common Python user/devel, I added the kemi support in an existing module and then did some basic tests, but the statement above should stay true. In my Lua scripts I used http/s, twitter, db and other Lua-specific libs. Probably you already noticed the examples in misc/examples/kemi/ -- they are a good starting point. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com ___ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kemi] porting module functions with input/output PV parameters
> > 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
Re: [sr-dev] [kemi] porting module functions with input/output PV parameters
Hello,
On 13/01/2017 15:30, Mititelu Stefan wrote:
> Hi,
>
> I've been reading about new kemi interface that will be available in
> 5.0. Writing configs in lua/python is awesome!!!
and javascript via app_jsdt to make it more awesome for the internet
world :-)
>
> I am currently looking into and trying to add kemi support for a
> module and have some questions:
>
> 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. For example:
- in kamailio.cfg you have:
xdbg( "r-uri is: $ru\" );
- in kamailio.lua you have:
KSR.dbg( "r-uri is: " .. KSR.pv.get("$rU") );
For shorting, one can just keep values locally if using same 'pv' many
times, like:
rU = KSR.pv.get("$rU");
KSR.dbg( "r-uri is: " .. rU );
if rU == "alice" then ...
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.
>
> 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().
If something is not clear regarding kemi, just ask more, I am happy to
try to clarify better.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
___
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kemi] porting module functions with input/output PV parameters
Hi, I've been reading about new kemi interface that will be available in 5.0. Writing configs in lua/python is awesome!!! I am currently looking into and trying to add kemi support for a module and have some questions: 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. 2. Will kemi support some other types besides int/str/none? (i.e. SR_KEMIP_ *PV*) Thank you, Stefan ___ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
