This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
devel:kamailio-5.0-design [2016/03/01 09:16] miconda [Exporting Functions To Embedded Interpreters] |
devel:kamailio-5.0-design [2016/04/25 23:05] miconda [Unit Test Framework] |
||
---|---|---|---|
Line 32: | Line 32: | ||
* it should be in a similar fashion as for adding functions to configuration file, but without fixup mechanism, so bare string/ | * it should be in a similar fashion as for adding functions to configuration file, but without fixup mechanism, so bare string/ | ||
+ | Interface fields: | ||
+ | |||
+ | * submodule name in embedded interpreter | ||
+ | * function name in embedded interpreter | ||
+ | * parameter types | ||
+ | * pointer to c function | ||
+ | |||
+ | Example: | ||
+ | |||
+ | <code c> | ||
+ | // export t_reply(200, | ||
+ | |||
+ | sr_exapi_t mod_exapi[] = { | ||
+ | { " | ||
+ | { 0, 0, {0}, 0} | ||
+ | }; | ||
+ | </ | ||
==== Routing Logic In Embedded Interpreters Scripting ==== | ==== Routing Logic In Embedded Interpreters Scripting ==== | ||
Line 39: | Line 56: | ||
* routing logic in an embedded language should allow reloading at runtime without kamailio restart | * routing logic in an embedded language should allow reloading at runtime without kamailio restart | ||
+ | === Implementation Ideas === | ||
+ | |||
+ | |||
+ | Example kamailio.cfg for native interpreter: | ||
+ | |||
+ | < | ||
+ | # core parameters | ||
+ | ... | ||
+ | |||
+ | # load modules | ||
+ | ... | ||
+ | |||
+ | # modules parameters | ||
+ | ... | ||
+ | |||
+ | routing=" | ||
+ | |||
+ | request_route { | ||
+ | ... | ||
+ | } | ||
+ | ... | ||
+ | reply_route { | ||
+ | ... | ||
+ | } | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Example kamailio.cfg for lua interpreter: | ||
+ | |||
+ | < | ||
+ | # core parameters | ||
+ | ... | ||
+ | |||
+ | # load modules | ||
+ | ... | ||
+ | |||
+ | # modules parameters | ||
+ | ... | ||
+ | |||
+ | routing=" | ||
+ | |||
+ | </ | ||
+ | |||
+ | The script / | ||
+ | |||
+ | < | ||
+ | function request_route() | ||
+ | ... | ||
+ | sr.t_on_branch(" | ||
+ | end | ||
+ | |||
+ | function reply_route() | ||
+ | ... | ||
+ | end | ||
+ | |||
+ | function my_branch_route() | ||
+ | ... | ||
+ | end | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Expected changes: | ||
+ | * each module that offers an interpreter for config will advertise a special structure with functions to be executed on various events (e.g., request received, reply received, etc...) | ||
+ | * keep the name of routing blocks for failure/ | ||
+ | * define the function names for routing blocks that are executed automatically | ||
+ | * such as: | ||
+ | * request_route | ||
+ | * reply_route | ||
+ | * onsend_route | ||
+ | * various event_route blocks (e.g., htable: | ||
+ | * eventually there can be a mapping of names used inside kamailio native config and functions inside the embedded interpreter that is inside each module, so each can have a naming pattern more suitable/ | ||
+ | * for event routes executed automatically (not the one armed for tm branch failure which sets the name at runtime), the pattern can be: | ||
+ | * modname_event_route(eventname) -- for example: | ||
+ | |||
+ | < | ||
+ | // event_route[htable: | ||
+ | function htable_event_route(evname) | ||
+ | if evname==" | ||
+ | ... | ||
+ | else | ||
+ | ... | ||
+ | end | ||
+ | </ | ||
===== Source Tree Structure ===== | ===== Source Tree Structure ===== | ||
Line 79: | Line 179: | ||
Reviving the exiting unit testing or selecting another framework. | Reviving the exiting unit testing or selecting another framework. | ||
+ | |||
+ | Available frameworks: | ||
+ | |||
+ | * http:// | ||
==== Minimal Unit Tests ==== | ==== Minimal Unit Tests ==== |