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

Daniel-Constantin Mierla miconda at gmail.com
Fri Jan 13 16:02:39 CET 2017


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20170113/966c18e7/attachment-0001.html>


More information about the sr-dev mailing list