[SR-Users] Last phase of integration for kamailio - ser

[Daniel-Constantin Mierla]

Hello,

we plan to start the last phase of integration between kamailio and ser. 
After about 4 years with same source code tree, there is still some 
overhead caused by several duplicated modules. Following the decision to 
go on with the most developed components and absorb the missing features 
from the duplicates, kamailio modules are those that will stay (move to 
modules/ eventually) and get updates when needed. We used same decision 
to keep the core and makefile system from ser, adding to it what was 
extra in kamailio.

I present next a summary of what is planned to happen:

1) Modules from modules_s/ that will be simply moved to modules/ because 
there is no conflict at all:
     - avp, avp_db, db_ops, eval, mangler, print, print_lib

2) Modules from modules_s/ that will be renamed and moved modules/ 
because it is mainly only conflict of name, but not in the backend 
(e.g., database):
     - auth_db => auth_dbattrs - because it uses (attribute,value) style 
to store subscriber profiles, which can be a preferred alternative for 
many out there
     - ldap => db2_ldap - it is a DB APIv2 connector to ldap server
     - bdb => db2_bdb - it is a DB APIv2 connector to berkeley db (to be 
double-checked)
     - xlog => xprintf - it uses %spec to print log messages with all 
the code inside the module - the only reason not discarding it and stick 
only to modules_k/xlog for the moment is because it is used from other 
modules, otherwise modules_k/xlog has more features (e.g., syslog 
facility, color printing, a.s.o)

3) Modules from modules_s/ that will be removed, after absorbing some 
extra features:
     - usrloc/registrar => get the ability to store AVPs per contact 
(modules_k is more advanced in features, like path/gruu/partial outbound 
support, publish presence states, etc.)
     - several modules must be reviewed: acc*, radius*, permissions, 
pike, gflags, options, timer

4) Modules from modules_s/ that will be removed, by moving to obsolete/ 
directory
    - the rest of them from modules_s/, like dialog, xcap, cpl-c, 
presence_b2b, dispatcher, dbtext, domain, etc.

The categories and their content are not nailed down, it is the purpose 
of this discussion to see if something was overlooked.

We hope to end this process in max 6 months time - after that will be a 
unique database schema and a unique set of modules. Flavour system in 
the Makefile will stay just for letting people choose easier the name of 
binary, otherwise everything will be the same (e.g., what is compiled, 
installed, etc).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda