Pull off the bandaid: Remove RTC prefix from all names

[maxhawkins]

• Reduces studdering: webrtc.RTCTrack -> webrtc.Track
• Makes it easier to find types by editor autocomplete
• Makes code read more fluently (less repetition)

Since we're breaking the API in 2.0, our only chance to
do this is now!

Relates to #408

[Sean-Der]

I am torn.

For Go code it is much better. Stuttering is really annoying (and makes autocomplete worthless sometimes)

But we are diverging from the spec. It might not be bad this time, but what if this creates a broken window situation. Since we diverge on this it makes it more likely that we will diverge in other places and it won't be a big deal.

One datapoint is that all the other versions (aiortc and ecmascript implementation) do use the RTC.. prefix.

[maxhawkins]

To counter the aiortc and ecmascript datapoint:

The Chromium WebRTC Native API only has a prefix in languages where namespaces are not supported. Objective-C and Ecmascript use the prefix. Java and C++ do not.

If users are used to programming against the Android client library or directly in C++ losing the prefix will be no problem.

[Sean-Der]

I have never used the Java/C++ APIs, reading about those now!

Do they implement the full spec? My assumption was that the Native API was completely different, when I see people on webrtc-discuss they are working at a completely different level.

[Sean-Der]

They have the same goals as us, from the top level docs here

The WebRTC Native APIs implementation is based on W3C’s WebRTC 1.0: Real-time Communication Between Browsers.

[maxhawkins]

My assumption was that the native API is the reference implementation for the WebRTC spec. Maybe I am mistaken though.

[coveralls]

Pull Request Test Coverage Report for Build 2052

• 908 of 999 (90.89%) changed or added relevant lines in 40 files are covered.
• 9 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.1%) to 79.328%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
icegatherer.go	12	13	92.31%
icetransport.go	13	14	92.86%
sctptransport.go	17	18	94.44%
track.go	4	5	80.0%
dtlstransport.go	16	18	88.89%
prioritytype.go	34	36	94.44%
sdptype.go	42	44	95.45%
api.go	0	3	0.0%
quictransport.go	10	13	76.92%
rtpsender.go	11	14	78.57%

Files with Coverage Reduction	New Missed Lines	%
api.go	1	53.85%
internal/mux/mux.go	2	92.5%
pkg/rtcerr/errors.go	6	40.0%

Totals
Change from base Build 2048:	0.1%
Covered Lines:	3895
Relevant Lines:	4910

---

💛 - Coveralls

[kixelated]

Yeah, the C++ native API powers the Chrome implementation. It's not 1:1 with the Javascript API mostly because of language differences.

https://webrtc.googlesource.com/src/+/master/api/peer_connection_interface.h

Stuff like you have to create a webrtc::PeerConnectionFactory with the encoders/decoder and thread handles. example: https://webrtc.googlesource.com/src/+/master/examples/peerconnection/client/conductor.cc#132

But yeah, it uses the webrtc namespace for the most part but a handful of things are prefixed with RTP. There's also a rtc namespace for a bunch of stuff (rtc_base folder).

[maxhawkins]

I was talking to Sean on Slack about whether or not to merge this. Since we can't decide whether to drop the RTC prefix or keep it, I thought we could put it to a vote. Can everyone fill this out or comment if they have any different ideas?

https://www.surveymonkey.com/r/6Y5X7GK

[mjmac]

Well, I’ll go on the record as being in favor of this change. It’s a nice idea to try and match the js API but in reality it’s not going to be copy/paste equivalent. If there has to be some translation anyhow, we might as make our library more idiomatic.

[Sean-Der]

Voted!

I think this is great, thank you so much for starting this :)

I say if yes is 50%+ we go for it

Everyone please vote if you get a chance. We can also have a sh script to fix this for people, so hopefully users will not be that annoyed.

[hugoArregui]

Voted! I think it makes sense

[kixelated]

I'm all for briefer APIs. The RTC prefix doesn't add anything and it's inconsistent.

[maxhawkins]

Nobody has voted no yet. Should we merge or give it a little more time?

[Sean-Der]

Merge it!

Fantastic work, sorry for the push back Max I was wrong

[maxhawkins]

No, thanks for holding us to a higher standard! This is a big change.

I'll see if I can write a new test to appease the coveralls and then we're good to merge.

[maxhawkins]

Quick! Someone approve it so we can merge before coveralls finishes and blocks the commit. :-)

Edit: looks like the extra test did the trick. It's rebased and ready to merge when you all are.