20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla <mico...@gmail.com>:
> Hello, > > most of the duplicated or ser-specific modules were sorted out at this time, > next is the situation with the remaining ones. > > A) modules that will be renamed using a prefix 'uid_', because they have a > database schema using unique id instead of username and domain: > - auth_db => uid_auth_db > - avp_db => uid_avp_db > - domain => uid_domain > - gflags => uid_gflags (not documented, but this module loads so called ser > global avps) > - uri_db => uid_uri_db Apart from trying to help people not to change their db schemas - are there any functionality differences. If it's only the schema I think we can kindly force a change for a major release and make these obsolete. I guess we just have to say "please" and duck. A major release should be able to change stuff, in my opinion. We've been maintaining dual code for many years to make migration to modules_k and modules easier. > > B) modules to become obsolete with some work to be done > - cpl-c - seems that giving a parameter with what user to be used for loading > the cpl scripts will make k and s versions compatible > - maxfwd - different names for config functions > - nathelper - some extra functionality, not sure if can be kept completely Maybe Andreas can look into this, as there is a lot of work going on with nathelper and the new rtpproxy anyways. > - textops - seems to have some extra cfg functions > - pike - has a rpc command I need to learn about this stuff, so I can take a first stab at porting the RPC command to modules_k. Time for xmas hacking. I propably will regret that part of the mail :-) /O > - registrar/usrloc - avps stored per contact > > C) modules to become obsolete, most probably without further work > - permissions - different structures/database table internally, but all > should be achieved using k version (data migration might be required) > > D) modules that needs further investigations > - rr - there seems to be some feature related to avps and record-route > parameters/cookies - this module could be just renamed at the end (like rrs) > > > E) Sample modules, not for real use - they can be kept in this directory > (modules_s[ample]) > - print > - print_lib > > If anyone has comments regarding these remarks, reply here. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > > _______________________________________________ > sr-dev mailing list > sr-...@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
