<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 13/01/2017 17:30, Mititelu Stefan
wrote:<br>
</div>
<blockquote
cite="mid:CAL82Oa1acoA9_pv_5PPNnmoG8bYEmTONnR6N=q9RMro1zpMKzg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
<br>
</span> The idea is to no longer pass names of variables
to the functions in the embedded language, but the
string value for it. <br>
<br>
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.<br>
<br>
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.</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">The idea is to no longer pass names
of variables to the functions in the embedded language,
but the string value for it.</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div>2. Will kemi support some other types besides
int/str/none? <span
style="color:rgb(51,51,51);font-size:14px;line-height:19.6px">(</span><span
style="color:rgb(51,51,51);font-size:14px;line-height:19.6px">i.e. </span><span
style="color:rgb(51,51,51);font-size:14px;line-height:19.6px">SR_KEMIP_<b>PV</b>)</span></div>
<div><span
style="color:rgb(51,51,51);font-size:14px;line-height:19.6px"><br>
</span></div>
</div>
</blockquote>
</span> 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.<br>
<br>
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.<br>
<br>
The common C function should accept only int, str* and
pv_spec_t* (for functions that need to write in a pv)
parameters.<br>
<br>
The current fixup system for native config converts at
some point to int/str using fixup_get_ivalue() and
fixup_get_svalue().<br>
</div>
</blockquote>
<div><br>
</div>
<div>I will also have a look in apy_kemi.c for
KSR.pv.get/set methods for a better understanding. Thanks!
:D</div>
</div>
</div>
</div>
</blockquote>
<br>
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).<br>
<br>
<br>
<blockquote
cite="mid:CAL82Oa1acoA9_pv_5PPNnmoG8bYEmTONnR6N=q9RMro1zpMKzg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> If something is not clear
regarding kemi, just ask more, I am happy to try to
clarify better.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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:</div>
<div>"</div>
<div>import myPythonFramework</div>
<div>import otherPythonLib</div>
<div># play with myPythonFramework<br>
</div>
<div># play with otherPythonLib<br>
</div>
<div>"</div>
<div>right?</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Probably you already noticed the examples in misc/examples/kemi/ --
they are a good starting point.<br>
<br>
Cheers,<br>
Daniel<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio World Conference - May 8-10, 2017 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
</body>
</html>