Henri Sivonen <hsivo...@iki.fi> writes:
> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
> wrote:
>> But that's not really important, I'm mostly concerned about
>> the stuff that we will ship in the future. The specific thing that I'm
>> worried about is Web Audio which is a huge spec and we may not be able to
>> implement all of it for quite a while for a variety of reasons, and it might
>> be difficult to decide whether implementing more of it will break existing
>> users, because, among other things, the spec is also changing.
>
> If a spec is actively changing in breaking ways, we shouldn’t ship an
> implementation to the release channel. OTOH, once an implementation
> has been shipped to the release channel and Web content depends on in,
> a reasonable spec editor won’t make breaking changes anymore.
>
> So if we agree that breaking changes are still necessary, we shouldn’t
> ship. If we think we need to ship, we need to tell the spec editor not
> to make breaking changes anymore.
This is a big issue for WebRTC.
The WebRTC API (and MediaStream API via the Media Capture Task Force and
getUserMedia()) is very much still in flux.
Chrome is shipping enabled-by-default soon, and will do so as
RTCPeerConnection. They had been using PeerConnectionNN, where NN was
bumped whenever a breaking change was done.
This was their comment: [1][2]
If you have been following the W3C WebRTC spec and looking at the
Chrome implementation, you will have noticed that our implementation
was not spec compliant.
With this week’s patches to Chromium and Webkit, Chrome is now a
editor’s-draft-compliant WebRTC implementation.
RTCPeerConnection is replacing PeerConnection00. RTCPeerConnection is
the API you will find in the upcoming stable version of Chrome, and the
last major API change before we go to a public stable release.
...
Once WebRTC goes into the stable channel of Chrome, API changes will
be done with a longer, smoother transition period.
However, I'd be *quite* surprised if there were no more breaking changes
to RTCPeerConnection.
Certainly there will be changes for navigator.getUserMedia(), which they have
prefixed as webkitGetUserMedia() (Opera has used getUserMedia(), and had
the API change under them several times.) At TPAC, the getUserMedia()
spec changed significantly.
So our problem will be: what do we ship in FF20? Right now we're behind
a pref, AND we're using mozRTCPeerConnection(). I also have no belief
that the spec will be nailed down for FF20 uplift, though I hope it will
be pretty stable by that point.
I'll point out that APIs have a lot of options other than simple naming:
(please excuse any syntax/etc errors):
* You can directly query for features
(mypeercon.supports("JSEP-with-swizzling"));
* You can test for sub-APIs (if (mypeercon.createFunnyOffer != undefined));
* You can design it to support multiple versions (mypeercon = new
RTCPeerConnection("API version NN please"));
* You can use the NN suffix naming ala Chrome (though they've dropped it now):
RTCPeerConnection00/01/etc as breaking changes are incorporated, and try
to support the previous version "for a while" (or for a long while).
Devs will use polyfills to smooth over these differences, as they always
do. These would at least make the polyfills fairly deterministic if the
editors and implementors are careful about marking 'breaking' changes.
WebRTC is a big spec, with lots still to be defined. It will be a Long
Time before it moves past editors-draft stage. We will *not* have a
reasonable option to avoid exposing it; the only question is how to do
so, and how to minimize problems in the future - especially given others
ahead of us on implementation (though we're catching up). We will try
hard to be API-equivalent to Chrome, but that may not be possible
without downgrading our spec-compliance in issues where we're closer to
the draft, for example. If we can't be 100% API-compatible with Chrome,
we'll need to define how a site/app will notice and handle the
differences (i.e. some level of polyfill...).
I wish I had a magic answer that would get the spec finished before
anyone ships this, but that's not happening. Sorry.
[1] http://www.webrtc.org/blog/apiupdatedtoreflectlatesteditorsdraft
[2] http://www.webrtc.org/blog/peerconnection00nowdeprecatedincanary
--
Randell Jesup, Mozilla Corp
remove ".news" for personal email
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
