[OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)

[ag at ag-projects.com]

Hello Richard,

This is not silly. Is very healthy to argue about it, now that the time has come. Here it is what you wrote:
"Many moons ago, the team at Sipwise was using a privately developed, closed source RTP proxy. It was designed to be used with the Openser "mediaproxy" module, and as such we called our project mediaproxy, even though it was completely unrelated to the AG Projects Mediaproxy.

Later on, we decided to redesign our mediaproxy from scratch and eventually make it open source. Thus, mediaproxy-ng was born. At around the same time, we decided to shift our focus away from the Openser "mediaproxy" module and support the control module "rtpproxy" instead (even though compatibility with the other module was retained).

Yet again later on, consensus among developers was that the future way to go for media/RTP proxying was to employ a JSON-like control protocol that allows complete rewriting of the entire SDP body. We went ahead and implemented this into mediaproxy-ng. As a new control module was required, we took the old "rtpproxy" module and modified it. As the new module was (and still is) intended as a drop-in replacement for the "rtpproxy" module (and not the unrelated "mediaproxy" module), we called it "rtpproxy-ng" to make transitioning easier.

Other people have suggested to call the new module "mediaproxy-ng" instead of "rtpproxy-ng", which would be more logical because it was meant to be used with the mediaproxy-ng daemon, but then that would imply that this module somehow is a fork or modification of the old "mediaproxy" module, which it isn't. All the functions within "rtpproxy-ng" are taken more or less directly from "rtpproxy" without even renaming them, so it makes sense to retain "rtpproxy" in the name of the module.

Also, there's no reason why "rtpproxy-ng" cannot be used with other RTP/media proxies if they choose to implement this new protocol. By no means is it exclusive to mediaproxy-ng.“

End of quote.

I am not amused to have to point to it. Building consensus around of chain of re-entrant poor choices is not an excuse for not be willing to rename your software now. Admit the mistake (it may not even be yours, things just evolved to this unfortunate state of affairs) and fix it now.

How about:

My name is Richard Fuchs and I made a new RTP media relay module that makes a difference, it does X, Y and Z features than no other modules of OpenSIPS do to date. I am aware that the software name was unfortunate as it collides with similar implementations but I CAN change it to fix the problem because I am the AUTHOR. I can change  the software name to fuchs-relay or whatever name avoids collisions. Can it be added to the project, what do you think? 

And the answer would be a big Yes, this is great addition, and welcome. Instead, you are trying to justify the chain of bad name choices and claim ‘consensus’ of developers that are not involved of this project.

Adrian


On 21 Feb 2014, at 22:16, Richard Fuchs <notifications at github.com> wrote:

> Actually it's not all that easy. Plus, I find it silly to argue about a mere name like that.
> 
> —
> Reply to this email directly or view it on GitHub.
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20140221/d0e03fa1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opensips.org/pipermail/devel/attachments/20140221/d0e03fa1/attachment-0001.pgp>