[SR-Users] debate: module interface

Daniel-Constantin Mierla miconda at gmail.com
Wed Jul 29 12:18:07 CEST 2009


Hello,

the new sip router core and librarization of kamailio management (MI) 
and statistics interfaces affected the module interface. At this time, 
although all the fields are still in the module interface, some are passive:
- mi commands exports
- statistics exports
- extra processes

The modules in the public GIT repository use the either mod_init or 
mod_register to export them, so everything should work as expected.

fyi: if you didn't know so far - mod_register is a function 
automatically called when a module is loaded, giving the possibility to 
export components from module in very early stage, e.g., transfomations 
must be exported via mod_register since they are lookep up while parsing 
the routing blocks -- mod_register is available in kamailio since 1.5, 
back ported from sip router core, you just need to implement it in the 
module, it is not part of module interface.

Back to module interface, the three fields mislead private module 
implementations as everything compiles ok, but at startup the fields are 
not actually exported. I propose to remove them and document the 
transition process to new interface, which is practically couple of code 
lines. It this way people migrating private stuff will notice the change 
and update.

Since we are here and we have to go through each K module and remove the 
fields from the module interface, maybe we can create a single interface 
for k and s modules. Doing a short analysis and considering the above 
three fields removed from k interface, then:

- K interface has extra
     - dlopen flags - needed to specify how the .so is open, required so 
far by perl module, iirc
    - PV exports - the list of pseudo-variables exported by module
    - the cmd (function) exports structure has a field to specify a free 
fixup function (not implemented for all exported commands). The goal is 
to allow calling functions exported by modules for higher application 
languages, like perl so far, where it is needed to free the memory 
allocated by fixup function

- S interface has extra
    - rpc exports - exported rpc commands
    - onbreak function - is this used?!? couldn't find docs about or a 
use case, so I consider it obsolete

Then common interface would be:
- name
- dlopen flags
- mod parameters
- mod commands with free fixup
- rpc commands
- PV exports
- mod init
- child init
- mod destroy
- onreply callback

Probably we can normalize it a bit more, comments and suggestions are 
welcome!

Thanks,
Daniel

-- 
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/





More information about the sr-users mailing list