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