W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2017

Re: [webrtc-pc] Have createOffer call addTransceiver() on offerToReceive.

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Mon, 11 Sep 2017 14:46:16 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-328552518-1505141165-sysbot+gh@w3.org>
@stefhak If you're thinking of [adapter.js](https://github.com/webrtc/adapter), it generally shims new APIs on older browsers, not old APIs on new ones. Much like babel.js lets sites write es7+ without worrying about older browsers.
 
That's in some sense the opposite of a legacy shim that perpetuates old APIs: Move to adapter.js to write against the latest API, not the oldest API. It solves the legacy burden for people who keep up with the spec, while *browsers* handle the other group. The doc language on this being a "shim to insulate apps from spec changes" is a bit misleading. It generally insulates apps from browser differences, *if* you follow the spec.

For this reason, production sites are encouraged not to use [adapter-latest.js](https://webrtc.github.io/adapter/adapter-latest.js), which is generally the least stable version, not the most stable (nor do they like such runtime dependencies anyway, which works out well). Adapter.js has minted breaking major version updates at least a couple of times in the last couple of years to keep up with spec changes.

So it requires "developer attention" to update a production site's copy of adapter.js, which means it's of limited use to mitigate web compat problems.

**There are two exceptions**: Legacy APIs on Safari, and `createObjectURL(stream)`. The thinking here was that by transitioning support from browsers to adapter.js in a *minor* adapter release, it would move this breakage off individual browser release calendars, and onto the adapter.js major version update calendar. Kudos to the Safari team here.

I suppose we could attempt a similar exception for `offerToReceiveX`, *provided browsers commit to ending support*. Basically we need to follow through on it, and yank adapter support eventually in a major adapter version, after all browsers have yanked support.

Accumulating exceptions in adapter.js hurt its reputation as the spec-reference module. We've heard confusion already from people who think it's a "bloated legacy library" when it is anything but. We want sites to use adapter, which means keeping it lean and forward-thinking.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1430#issuecomment-328552518 using your GitHub account
Received on Monday, 11 September 2017 14:46:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:45 UTC