On 12/20/12 3:25 PM, Olle E. Johansson wrote:
20 dec 2012 kl. 15:17 skrev Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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.
There are some different functionalities (global avps, domain avps). The
most important aspect is that there are dependencies between them,
that's why some of them cannot be removed. I think it is fine to keep
them for a while at least, eventually giving 1-2 development cycles to
see the usage and ask people to move to the other alternatives if
discarding is the preferred way or no maintainers are taking care of them.
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.
I think Ovidiu Sas looked at it when he split the rtpproxy out in
a
dedicated module.
Cheers,
Daniel
- 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-dev(a)lists.sip-router.org
>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda