6 Apr
2020
6 Apr
'20
11:34 a.m.
Hi,
We started to migrate our Lua scripts to KEMI but we use [0]
sr.xavp.get_keys() and sr.xavp.get() functions that return an array
and a dictionary. It seems that KEMI has no support for complex data
types.
So, I think we still need a way to extend the interpreters with richer
functions that must be implemented on all flavours or create some c
abstractions to support arrays and dictionaries in KEMI.
Comments/Ideas?
Victor
[0] https://www.kamailio.org/wiki/embeddedapi/devel/lua#srxavp
8 Apr
8 Apr
10:56 a.m.
Hello,
the old sr module should be now part of app_lua_sr module, just in case
someone missed it. The module can be used along with app_lua and the two
objects KSR and sr can be used together in the same config.
Regarding your topic - two options right now:
1) if it is something very specific to an interpreter, it can be added
as part of KSR.x object -- each app_xyz implements it internally,
because of specifics of those functions (like KSR.x.exit())
2) we can add a new data type for SR_KEMIP_INT inside sr_kemi_xval_t,
like a list of named values with type (items with (name, type, value)),
then see if for each interpreter if it can handle them, if not, then
they should not be exported to KSR object, so they won't be available in
the KEMI script for that interpreter.
Cheers,
Daniel
On 06.04.20 10:34, Victor Seva wrote:
Hi,
We started to migrate our Lua scripts to KEMI but we use [0]
sr.xavp.get_keys() and sr.xavp.get() functions that return an array
and a dictionary. It seems that KEMI has no support for complex data
types.
So, I think we still need a way to extend the interpreters with richer
functions that must be implemented on all flavours or create some c
abstractions to support arrays and dictionaries in KEMI.
Comments/Ideas?
Victor
[0] https://www.kamailio.org/wiki/embeddedapi/devel/lua#srxavp
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
12:14 p.m.
On 4/8/20 9:56 AM, Daniel-Constantin Mierla wrote:
Hello,
the old sr module should be now part of app_lua_sr module, just in case
someone missed it. The module can be used along with app_lua and the two
objects KSR and sr can be used together in the same config.
Yes, this is my actual approach until we create the alternative. I've
migrated everything to KEMI and just use sr for those two missing functions.
Regarding your topic - two options right now:
1) if it is something very specific to an interpreter, it can be added
as part of KSR.x object -- each app_xyz implements it internally,
because of specifics of those functions (like KSR.x.exit())
2) we can add a new data type for SR_KEMIP_INT inside sr_kemi_xval_t,
like a list of named values with type (items with (name, type, value)),
then see if for each interpreter if it can handle them, if not, then
they should not be exported to KSR object, so they won't be available in
the KEMI script for that interpreter.
I'll start working on the point 2 since I think these two functions are
generic and useful for all interpreters. Expect KEMI internal questions
from my from now on :-)
Thank you,
Victor
1693
days inactive
1695
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Victor Seva