Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Peter Thatcher <[e-mail]>]

On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba <[e-mail]>wrote:

> Robin said:
>
> "If provided a lower level API that works without SDP where the individual
> network/media component wiring/attributes can be controlled, we could
> create the same WebRTC API that exists today'
>
> [BA] I wouldn't require a shim to provide "the same WebRTC API that exists
> today" because that API is very underspecified, so that it is not possible
> to produce a set of conformance tests for it without reverse engineering.
>  And of course, that reverse engineered specification would only remain
> valid until the next set of SDP hacks invalidated it.
>

Once thing you *could* do (I'm not saying this is a good idea) is take an
open source browser (let's pick Chrome) implement a "WebRTC 2.0" API, and
then build the WebRTC 1.0 on top of it.  You could then port the WebRTC 1.0
SDP code (for reference, it's here:
https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc)
on to the WebRTC 2.0 API.  At that point, you would have an "1.0 on 2.0"
API that is the same as the "original 1.0" API, or at least as close as
could possibly be done.  And at the same time, you'd have the 2.0 available
to JS to use.

Repeat that process for all (2) browsers that have implemented the WebRTC
1.0 API.  What could go wrong :)?



>
> So while the shim might provide a "similar high level WebRTC API", holding
> WebRTC API 2.0 to a "bug for bug" compatibility standard is neither
> feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate
> 1.0, not to increase the WebRTC API implementation barriers even further.
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>