git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
9 May
2009
9 May
'09
12:15 p.m.
Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
---
{modules_k => modules}/lcr/Makefile | 0
{modules_k => modules}/lcr/README | 0
{modules_k => modules}/lcr/doc/Makefile | 0
{modules_k => modules}/lcr/doc/lcr.xml | 0
{modules_k => modules}/lcr/doc/lcr_admin.xml | 0
{modules_k => modules}/lcr/hash.c | 0
{modules_k => modules}/lcr/hash.h | 0
{modules_k => modules}/lcr/lcr_mod.c | 0
{modules_k => modules}/lcr/lcr_mod.h | 0
{modules_k => modules}/lcr/mi.c | 0
{modules_k => modules}/lcr/mi.h | 0
modules_s/lcr/Makefile | 17 -
modules_s/lcr/README | 259 ------
modules_s/lcr/doc/Makefile | 4 -
modules_s/lcr/doc/functions.xml | 17 -
modules_s/lcr/doc/lcr.xml | 121 ---
modules_s/lcr/doc/params.xml | 235 ------
modules_s/lcr/lcr_mod.c | 1113 --------------------------
modules_s/lcr/lcr_mod.h | 61 --
modules_s/lcr/lcr_rpc.c | 104 ---
modules_s/lcr/lcr_rpc.h | 35 -
modules_s/lcr/ser-lcr.cfg | 24 -
22 files changed, 0 insertions(+), 1990 deletions(-)
Diff:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=a3f…
10 May
10 May
4:15 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 09, 2009 at 18:15, Juha Heinanen <jh(a)tutpro.com> wrote:
Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
Andrei
4:26 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
i don't understand why. i dig
eg pull
before i started working on this and expected my repo to be up to date.
it seems i'm totally incompetent to work with git.
-- juha
4:36 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 10, 2009 at 11:26, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
No it doesn't have anything to do with git. I meant modules_s/lcr should
have been merged with modules_k/lcr, before modules_s/lcr was remvoed
and modules_k/lcr moved into modules/lcr.
There were some changes in modules_s/lcr mostly related to external apis
and rpc support which are not in modules_k/lcr.
Some of these changes might be bug fixes (e.g. the db stuff, I don't
know how lcr uses db, but it looks like the k version intializes db
connections from all the processes ?).
The rpc stuff means that someone used to do sercmd lcr.reload would
have now to use something different (but rpc support should be trivial
to add, it even was in separate files: lcr_rpc.h and lcr_rpc.c).
Also the (s) lcr used the new db api, while (k) lcr uses the old one, so
from this point of view it's a step-back (we support 2 versions now, but
the old version will be slowly obsoleted).
Andrei
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
i don't understand why. i dig
eg pull
before i started working on this and expected my repo to be up to date.
it seems i'm totally incompetent to work with git. 
4:46 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
No it doesn't have anything to do with git. I
meant modules_s/lcr should
have been merged with modules_k/lcr, before modules_s/lcr was remvoed
and modules_k/lcr moved into modules/lcr.
ok, the move then needs to somehow be reverted and we need to have two
versions of lcr module: s version that has ser interface stuff and k
version that scales.
-- juha
6:04 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
andrei,
thanks for pointing the db init issue. in k lcr module database is only
accessed when module is initialized and when a reload command is given
via mi interface. i'll try to figure out, how to restrict db init to
those processes.
-- juha
6:32 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 10, 2009 at 13:04, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
For the module intialization db, you could close the db connections
afterwards. You could use either mod_init() or child_init() with
rank==PROC_INIT.
When we'll add the ser rpc interface to it, things will change though:
- we'll need DB for PROC_RPC and PROC_FIFO (the binrpc transport and
fifo transport).
- we'll need DB for all the tcp and tls ser processes, for the xml
transport (ser xmlrpc does not run in a separate process, it reuses
ser parser for the HTML requests). This would mean everything
except PROC_INT, PROC_MAIN, PROC_TIMER, PROC_TCP_MAIN
(or everything with rank >0 + PROC_RPC + PROC_FIFO).
Andrei
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
andrei,
thanks for pointing the db init issue. in k lcr module database is only
accessed when module is initialized and when a reload command is given
via mi interface. i'll try to figure out, how to restrict db init to
those processes.
6:26 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
- possible wrong db init from all the processes (see
8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_RPC -2 /* RPC type process */
#define PROC_FIFO PROC_RPC /* FIFO attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
#define PROC_UNIXSOCK -5 /* Unix socket server */
#define PROC_ATTENDANT -10 /* main "attendant process */
#define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized
only by process that executes mi commands?
-- juha
6:38 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 10, 2009 at 13:26, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
I don't know :-)
Theoretically it should be PROC_RPC, but I'm not sure the kamailio mi
transport modules really work, or need some "porting".
A quick grep on mi_xmlrpc showed that fork_process use 100 as rank.
I think it should use PROC_RPC (anyway something special, meaning not a
positive number).
Daniel?
Andrei
- possible wrong db init from all the processes
(see 8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_RPC -2 /* RPC type process */
#define PROC_FIFO PROC_RPC /* FIFO attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
#define PROC_UNIXSOCK -5 /* Unix socket server */
#define PROC_ATTENDANT -10 /* main "attendant process */
#define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized
only by process that executes mi commands? 
11 May
11 May
3:34 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Hello,
On 05/10/2009 01:38 PM, Andrei Pelinescu-Onciul wrote:
On May 10, 2009 at 13:26, Juha Heinanen
<jh(a)tutpro.com> wrote:
MI works now. I have been tested it a lot with fifo so far.
Andrei Pelinescu-Onciul writes:
I don't know :-)
Theoretically it should be PROC_RPC, but I'm not sure the kamailio mi
transport modules really work, or need some "porting".
- possible wrong db init from all the processes
(see 8fb14f, 9961e8)
k only has these ranks:
#define PROC_MAIN 0 /* Main Kamailio process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
whereas sr has these:
#define PROC_MAIN 0 /* Main ser process */
#define PROC_TIMER -1 /* Timer attendant process */
#define PROC_RPC -2 /* RPC type process */
#define PROC_FIFO PROC_RPC /* FIFO attendant process */
#define PROC_TCP_MAIN -4 /* TCP main process */
#define PROC_UNIXSOCK -5 /* Unix socket server */
#define PROC_ATTENDANT -10 /* main "attendant process */
#define PROC_INIT -127 /* special rank, the context is the main ser
which rank should i test in child_init if i want db to be initialized
only by process that executes mi commands?
A quick grep on mi_xmlrpc showed that fork_process use
100 as rank.
It is 100, indeed for fifo. Checking the code, I think has to be
PROC_NOCHILDINIT because the MI calls a different child init function
that is added in the mi_export_t structure. Therefore module's child
init should not be called for MI processes.
Cheers,
Daniel
I think it should use PROC_RPC (anyway something
special, meaning not a
positive number).
Daniel?
Andrei
--
Daniel-Constantin Mierla
http://www.asipto.com/
4:50 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Daniel-Constantin Mierla writes:
It is 100, indeed for fifo. Checking the code, I think
has to be
PROC_NOCHILDINIT because the MI calls a different child init function
that is added in the mi_export_t structure. Therefore module's child
init should not be called for MI processes.
daniel,
indeed, in lcr module i have
static mi_export_t mi_cmds[] = {
{ MI_LCR_RELOAD, mi_lcr_reload, MI_NO_INPUT_FLAG, 0, mi_child_init },
{ MI_LCR_GW_DUMP, mi_lcr_gw_dump, MI_NO_INPUT_FLAG, 0, 0 },
{ MI_LCR_LCR_DUMP, mi_lcr_lcr_dump, MI_NO_INPUT_FLAG, 0, 0 },
{ 0, 0, 0, 0 ,0}
};
and
static int mi_child_init(void)
{
return lcr_db_init(&db_url);
}
also, i lcr module i don't have any other child_init function defined.
my conclusion thus is that lcr module db initialization is exactly as it
should be.
-- juha
5:04 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Hello,
On 05/11/2009 11:50 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I have changed that the MI processes are started with PROC_NOCHLDINIT.
The init should be now as in K - mi processes call only mi_child_init.
Anyhow, probably it was pretty ok before as well -- I tested mi fifo
several times without any issue -- now is just safer.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
It is 100, indeed for fifo. Checking the code, I
think has to be
PROC_NOCHILDINIT because the MI calls a different child init function
that is added in the mi_export_t structure. Therefore module's child
init should not be called for MI processes.
daniel,
indeed, in lcr module i have
static mi_export_t mi_cmds[] = {
{ MI_LCR_RELOAD, mi_lcr_reload, MI_NO_INPUT_FLAG, 0, mi_child_init },
{ MI_LCR_GW_DUMP, mi_lcr_gw_dump, MI_NO_INPUT_FLAG, 0, 0 },
{ MI_LCR_LCR_DUMP, mi_lcr_lcr_dump, MI_NO_INPUT_FLAG, 0, 0 },
{ 0, 0, 0, 0 ,0}
};
and
static int mi_child_init(void)
{
return lcr_db_init(&db_url);
}
also, i lcr module i don't have any other child_init function defined.
my conclusion thus is that lcr module db initialization is exactly as it
should be.
4:55 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen
<jh(a)tutpro.com> wrote:
lcr modules do not have to be merged (apart from the changes necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable.
Jan.
Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
5 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 11, 2009 at 10:55, Jan Janak <jan(a)iptel.org> wrote:
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
We need the rpc interface and maybe the db api.
I could add the rpc interface to the k version (it's trivial anyway) and
take care of the db init for it.
I don't know how difficult would be to switch it to the new db, but I
assume it would be trivial too (since lcr doesn't do any advanced db
stuff).
Andrei
On May 09, 2009 at 18:15, Juha Heinanen
<jh(a)tutpro.com> wrote:
lcr modules do not have to be merged (apart from the changes necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable. Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
5:07 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On 11-05 11:00, Andrei Pelinescu-Onciul wrote:
On May 11, 2009 at 10:55, Jan Janak
<jan(a)iptel.org> wrote:
If you need it then take Juha's version and add rpc equivalents to mi commands
on top of his code.
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
We need the rpc interface and maybe the db api.
I could add the rpc interface to the k version (it's trivial anyway) and
take care of the db init for it. On May 09, 2009 at 18:15, Juha Heinanen
<jh(a)tutpro.com> wrote:
lcr modules do not have to be merged (apart from the changes necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable. Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8) I don't know how difficult would be to switch it
to the new db, but I
assume it would be trivial too (since lcr doesn't do any advanced db
stuff).
It should not be that hard, but it is a lot of manual work. This kind of
change is not strictly necessary, thus I'd like to wait with this a bit, until
the all the code is more stable and working again.
Jan.
5:14 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Jan Janak writes:
i agree with that. even if changing database code would be
straightforward in theory, there exist lots of db related statements in
the code. changing them would take time and would easily lead to typos.
-- juha
I don't
know how difficult would be to switch it to the new db, but I
assume it would be trivial too (since lcr doesn't do any advanced db
stuff).
It should not be that hard, but it is a lot of manual work. This kind
of change is not strictly necessary, thus I'd like to wait with this
a bit, until the all the code is more stable and working again.
5:09 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
I don't know how difficult would be to switch it
to the new db, but I
assume it would be trivial too (since lcr doesn't do any advanced db
stuff).
it does use DB_CAP_FETCH, but i don't know if that counts "advanced".
-- juha
5:05 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Jan Janak writes:
jan,
i think rpc interface would need to be added if someone is currently
using it with ser lcr module.
by the way, how do you use your rcp interface from python or php?
-- juha
They should
have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes
necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable.
5:12 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 11, 2009 at 12:05, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
jan,
i think rpc interface would need to be added if someone is currently
using it with ser lcr module.
by the way, how do you use your rcp interface from python or php?
xmlrpc (loadmodule "xmlrpc" from .cfg and then it should work with
standard xmlrpc libs).
There might a quirk or too (we have docs in sip_router/doc/rpc, but
it's only an xml, no auto-generated html or txt and it should be
re-organized a little since the docs are from the time we had only
xmlrpc and they don't take into account the binary rpc/ctl modules part
or the fifo).
Juha, it's ok with you if I add the rpc support to lcr? It would help
see what exactly would be needed for a module to support both mi and
rpc (for example since in ser modules the rpc interface is part of the
module interface we have to register rpc functions in a different way
in kamailio modules).
Andrei
They
should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes
necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable.
5:15 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Andrei Pelinescu-Onciul writes:
xmlrpc (loadmodule "xmlrpc" from .cfg and
then it should work with
standard xmlrpc libs).
ok.
Juha, it's ok with you if I add the rpc support
to lcr? It would help
see what exactly would be needed for a module to support both mi and
rpc (for example since in ser modules the rpc interface is part of the
module interface we have to register rpc functions in a different way
in kamailio modules).
sure, please go ahead.
-- juha
5:19 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On 11-05 12:05, Juha Heinanen wrote:
Jan Janak writes:
jan,
i think rpc interface would need to be added if someone is currently
using it with ser lcr module.
OK, how about making the MI function also available through the RPC interface
in SER? That should be trivial to do, assuming that you already have the
functions exported through the MI interface.
They
should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface
- new db api
- possible wrong db init from all the processes (see 8fb14f, 9961e8)
lcr modules do not have to be merged (apart from the changes
necessary to make
it work with the new core). Juha's version in the kamailio tree is more
advanced than what we had, in SER I only kept Juha's original lcr version
compilable. by the way, how do you use your rcp interface from
python or php?
Through the xml-rpc interface. There is the xmlrpc module in modules_s which
exports all functions registered with the rpc interface as xml-rpc methods. I
called those function from python programs directly. I also know that Karel
extended serweb (written in php) with xml-rpc so serweb is able to call those
functions too.
Jan.
4:59 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen
<jh(a)tutpro.com> wrote:
That's not necessary, the rcp interface was only used to reload the data from
the database and kamailio version has this too.
Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface - new db api
Not necessary either, it can work with the old db interface, in case of lcr it
does not matter whether we use prepared statements or not because the module
works primarily with the memory cache.
- possible wrong db init from all the processes (see
8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
Jan.
5:02 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On May 11, 2009 at 10:59, Jan Janak <jan(a)iptel.org> wrote:
But isn't it a step backwards? At some point in the future we'll
obsolete anyway the old db.
Andrei
On 10-05 10:15, Andrei Pelinescu-Onciul wrote:
On May 09, 2009 at 18:15, Juha Heinanen
<jh(a)tutpro.com> wrote:
That's not necessary, the rcp interface was only used to reload the data from
the database and kamailio version has this too. Module: sip-router
Branch: master
Commit: a3f16850cd2a897710cb0a56174e9f64dcc77653
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3f1685…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat May 9 19:14:18 2009 +0300
* Moved lcr module from modules_k to modules and removed it from modules_s.
They should have been merged.
Looking only at recent commit logs, you lost from modules_s/lcr:
- rpc interface From my point of view it is. It's lost
functionality when going from ser
version to k version.
- new db api
Not necessary either, it can work with the old db interface, in case of lcr it
does not matter whether we use prepared statements or not because the module
works primarily with the memory cache. - possible wrong db init from all the processes
(see 8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
5:13 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
On 11-05 11:02, Andrei Pelinescu-Onciul wrote:
I think it is not. Juha's version of lcr module is much more advanced than the
version we had in ser cvs. Basically, I only kept lcr in ser cvs compilable but
I never tested it (even after the db changed) because we did not use the
module.
Because Juha is the owner of the code, I want him to adopt the version he is
familiar with and when we decide that we continue with migration of kamailio
modules to the new db api then I will either send him a patch or provide a
migration guide.
Because we do not compromise performance in this particular case, it is fine
to stick with the older db api version, to make Juha's life easier (we already
have enough changes to adapt to already).
Jan.
Not necessary
either, it can work with the old db interface, in case of lcr it
does not matter whether we use prepared statements or not because the module
works primarily with the memory cache.
But isn't it a step backwards? At some point in the future we'll
obsolete anyway the old db.
5:08 a.m.
New subject: [SR-Dev] git:master: * Moved lcr module from modules_k to modules and removed it from modules_s .
Jan Janak writes:
jan,
if some ser user has a management system that updates lcr db tables and then
makes rpc call to reload them into memory, then that application would
stop working.
as i mailed based on daniel's responce, there is nothing wrong with db
init in current k lcr module.
-- juha
- rpc
interface
That's not necessary, the rcp interface was only used to reload the data from
the database and kamailio version has this too. - possible
wrong db init from all the processes (see 8fb14f, 9961e8)
That's the only thing, imho, that needs to be changed.
5681
days inactive
5683
days old
24 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com -
Juha Heinanen
-
root＠tutpro.com