<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><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><br></div><div><br></div><div>Thank you</div><div>Stefan</div></div></div></div>