Hi Stan,
Some automatic way to convert the "nathelper" to "rtpproxy" module name
may be misleading, I think - especially that the set of functions in the
2 modules will be different (as set and names).
A better possible approach can be keep the "nathelper" module as an
dummy module that tells (at load time) the whole migration story so
that, you can load the proper module.
Regards,
Bogdan
Stanisław Pitucha wrote:
On 2 March 2011 13:47, Razvan Crainea <razvancrai...@opensips.org> wrote:
Note that there will be no functional changes, but only structural ones, all
current functions exported by nathelper module will still be available (some
name changes might be possible though), just that they will be provided by
the new module or nat_traversal module .
Since the functions themselves don't change, can we still have
"nathelper.so" name treated like a "fake module" that will load the
actual new ones? We already had some problems with the xlog module
removed (config changes in a revision, not even minor, update) - maybe
this time it could be done in a nicer way this time :)
I'd like to propose that if there's a loadmodule request that matches
"^(.*)/nathelper.(.*)$" it should automagically:
1. WARN that it's deprecated and functions are in rtpproxy and nat_traversal.
2. try to load modules from $1/rtpproxy.$2 and $1/nat_traversal.$2 and
if both can be found - do not fail.
Same for 'mangler' and 'nat_traversal' itself. I'm pretty sure that
could solve some problems in the future (just recall the number of
people asking about xlog on irc and some of the posts on the mailing
list).
Regards,
Stan
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
