20 Nov
2008
20 Nov
'08
6:59 p.m.
On Nov 20, 2008 at 23:44, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 11/20/08 22:36, Andrei Pelinescu-Onciul wrote:
I did some quick experimental work:
- copied kamailio db/* to sip-router/lib/sk_dbk
- edited the lib/print Makefile: changed name to sk_dbk and
added INCLUDES=-I.. (hack so I don'thave to change all the includes
, like ../str.h to ../../str.h)
- modifiedkamailio db_mysql:
- Makefile - added:
DEFS+=-DKAMAILIO_MOD_INTERFACE
SERLIBPATH=../../lib
SER_LIBS=$(SERLIBPATH)/sr_dbk/sr_dbk
- changed all the ../../db/*.h includes to ../../lib/sk_dbk/*.h :
perl -i.bak -pe "s#/db/#/lib/sr_dbk/#" *.[ch]
and then it compiled! It even loads (I haven't tested if it actually
works but probably it does).
Next I tried speeddial:
- same Makefile changes as above
- same perl: perl -i.bak -pe "s#/db/#/lib/sr_dbk/#" *.[ch]
- replace act.elem[] with act.val[]
- update do_action() call:
+ struct run_act_ctx h;
+ init_run_actions_ctx(&h);
- if (do_action(&act, _m) < 0)
+ if (do_action(&h, &act, _m) < 0)
So with very little work (add 3 lines to the makefile and run perl one
liner) one can convert a kamailio db module to libsr_dbk
(kamailio db interface in a library form).
Luckily there don't seem to be any symbol name conflicts between the
ser db api and the kamailio db api so they could coexist in theory
(e.g. load both ser mysql and k db_mysql and then you could mix ser db
using modules with k db using module).
Shall I commit the lib, or do we try the hard part and write a
wrapper for kamailio db api using ser db api?
Andrei
siputils is the first kamailio module that did
succesfully run on
sip-core.
I did only 2 small changes:
- added DEFS+=-DKAMAILIO_MOD_INTERFACE to the Makefile
- s/MIN/MIN_int
There are a few modules that would need a little bit more changes, like
everything using core send functions (they changed a bit in ser),
do_action() and build_*, but in all this cases these are minor updates.
More will be compileable as soon as we unify the fixups, but I think the
biggest problem right now is the DB interface (from a module point
of view, we still haven't unified the config file).
I think both of them can co-exists. I see no other conflicts than naming
space -- so we need at least renaming of the db directory. Also they can
be moved as library.