Resolve IDL type conflict with WebRTC 1.0

[saschanaz]

RTCIceCandidate
RTCIdentityAssertion
RTCRtpCapabilities
RTCRtpContributingSource
RTCCertificate
RTCDataChannel
RTCDtlsTransport
RTCIceTransport
RTCRtpReceiver
RTCRtpSender
RTCSctpTransport

These interfaces/dictionaries have same-named types on WebRTC with slightly different forms. Can we resolve this conflict by renaming or converting to partial interfaces/dictionaries, etc?

[lgrahl]

If I understand you correctly, using partial interfaces/dicts would require to both look at this spec and the WebRTC spec then? That doesn't sound like a good idea as the WebRTC spec isn't stable. It would require keeping the ORTC spec in sync with the WebRTC spec all the time. I don't think that's viable. Furthermore, if you have ever looked at an IETF RFC/draft, you will probably know that referencing other RFCs that reference other RFCs, ... can be really tedious. But that's just my personal opinion.

Conflicts of course have to be resolved over the time and @aboba and @robin-raymond are doing a great job on that. But I suppose everyone would be delighted if others would jump in and help them. :)

[saschanaz]

Do you mean that ORTC will manage a separate set of IDLs forever, or is waiting WebRTC being stable? Several other W3C specs refers other specs when they use definition of other specs, and I think they are even trying to remove duplication on purpose (probably) to prevent WebIDL-binding implementations from suffering type conflict. (For example, see http://www.w3.org/TR/2016/WD-cssom-view-1-20160317/#extensions-to-the-mouseevent-interface)

[aboba]

As issues arise in WebRTC 1.0 object model implementations and changes are made, we will try to keep the ORTC object model in sync so that we can preserve the ability to implement WebRTC 1.0 on top of ORTC. If you notice a discrepancy, please file a "1.0 compatibility" issue.

While the objects you mention are common to both specifications, ORTC has the IceGatherer, IceTransportController and RtpListener objects which are not in WebRTC 1.0. So there are some differences which can be expected to persist. Because of this, as well as to maintain readability (we want the ORTC specification to be understandable without having to refer to WebRTC 1.0), we are maintaining distinct (though hopefully compatible) WebIDL.

[saschanaz]

I think the current situation causes implementers to carefully check what is already defined in WebRTC and what is not when getting their own IDL copy to bind, but I have to admit this is just my personal assumption as I'm not an implementer. However, I can say that ORTC is the only spec duplicating everything among the web specs in my list... (The list currently not includes ORTC because of the duplications)

[lgrahl]

@aboba Just for my understanding: But it should always be the case that public attributes, methods and events are compatible to the WebRTC spec then?

[aboba]

@lgrahl In practice, this needs to be the case because WebRTC 1.0 objects are being exposed on top of ORTC.