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

[Robin Raymond <[e-mail]>]

You are absolutely correct, that it is an unobtainable goal to produce a 
shim 1-for-1 compatible without reverse engineering.

In the draft:
http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt

We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim 
compatibility statement" that it would not be the goal of this shim to 
do that. I think we have to work towards producing a shim that follows 
the spirit of the current WebRTC API rather than emulating the exact 
letter of every feature (and bug), especially since the feature 
definitions are vague. As any JS shim could be forked and modified, if a 
particular "feature/bug" needed to be emulated by someone it could be 
done by the developer needing the specialized behavior. Every JavaScript 
developer will have full control over the shim's code or which shim(s) 
to use.

-Robin


> Bernard Aboba <mailto:[e-mail]>
> 27 June, 2013 12:14 AM
> 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.
>
> 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.