Henri Sivonen <hsivo...@iki.fi> writes:
> On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup <rjesup.n...@jesup.org> wrote:
>> The WebRTC API (and MediaStream API via the Media Capture Task Force and
>> getUserMedia()) is very much still in flux.
>
> I’m not familiar with these specs, so I don’t know why they are still in flux.
Mostly because a) they're big, b) they involve complex and
still-being-defined underlying protocols coming from the IETF, like
signaling (JSEP (being defined for WebRTC/rtcweb) and SDP), c) as we get
initial implementations up, gain experience with them and start using
the more complex cases, we're realizing some earlier assumptions were
flawed (the recent getUserMedia() API change to return a (blocked)
stream immediately before permissions are granted (or not) is an
example, to speed call-answer time in apps).
>> Chrome is shipping enabled-by-default soon, and will do so as
>> RTCPeerConnection.
>
> Why do they want to ship something that is still in flux? Who is
> expected to use an in-flux API and be able to deal with the API being
> in flux? (Web developers in general are not up to the task of tracking
> in-flux APIs.)
Telecom/Skype-like/etc service providers very much want to get access to
these and to deal with the flux. These generally are NOT typical web
developers; these tend to be people with a lot of telecom experience
formerly working with SIP or similar applications (sometimes built on
Flash using RTFMP (the author of which is part of the effort)).
Small demo apps may break (or be dropped to a deprecated interface) and
not be updated. This is quite true.
>> Once WebRTC goes into the stable channel of Chrome, API changes will
>> be done with a longer, smoother transition period.
>
> There’s a risk that the old API versions stick around forever, then.
> Apple will basically never be removing their -webkit- CSS stuff. Also,
> the period for Chrome to transition from H.264 to WebM seems to
> continue indefinitely.
Understood, though those are quite different issues from this. And
we've pointedly warned app devs we'd be removing old APIs even if we
support them for a while, and have done so (or rather Chrome has).
>> However, I'd be *quite* surprised if there were no more breaking changes
>> to RTCPeerConnection.
>
> Why and how do the breaking changes arise? Shouldn’t implementors just
> say “no” to mere “nice to have” tweaks at this point?
See above. We're not at the tweak phase, we're finding actual flaws in
functionality as we try to write more complex applications (though it is
firming up; we may be past the major changes phase with the last
getUserMedia change, but I wouldn't put heavy money on it.).
FYI, I may not have been clear: Chrome has dropped the API version
suffix, but they're still prefixed. This means an app can distinguish
between us, but to track finer changes it will need to UA sniff or
feature-detect in some manner (like recently when we implemented
mediastream.stop() and forced apps to use it properly, or when we added
basic constraint support).
I *liked* the version suffix idea because if thing change, you know *and
can key off it temporarily* instead of getting vague "it stopped
working" reports and being forced to only support old or new (or fiddle
with unplanned detection code). Also, as we converge, we can use the
same suffix as Chrome if we have the same API (more applicable to
smaller changes than all of WebRTC, but still useful).
>> So our problem will be: what do we ship in FF20?
>
> I am not familiar with the APIs in question, but the policy I proposed
> would answer:
>
> Either don’t ship in Firefox 20, if there’s something worthwhile to
> wait for, or, if waiting is not an option, ship in Firefox 20 and tell
> the WG to stop making breaking changes (enforced by refusing to
> implement breaking changes if the WG tries to make them nonetheless).
See above. I'm afraid those aren't viable options. We are in close
contact with most people using these APIs, and they generally know the
APIs are in flux, and that they must track changes. It is a somewhat
different community used to interacting with standards bodies (and
dealing with standards like SIP where every device implements a
different subset of the HUGE number of RFCs (plus device-specific
quirks)). Our current state is actually far more "standard" than VoIP
people are used to.
>> 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));
>
> If "JSEP-with-swizzling" or createFunnyOffer ever went away, Web apps
> would break. (One can be sure that a scenario where all Web apps
> gracefully handle the feature going away is a theoretical scenario.)
Not so theoretical in this case, though it's not guaranteed. With two
platforms (so far) implementing and progressing unevenly, one must
either prefix/suffix or use feature queries (as we don't want UA sniffing!)
> If the plan is for them to never go away, they should just be part of
> the spec the way document.write() is even though document.write() is
> not a nice feature. In which case the issue reduces to shipping
> partial features rather than shipping features with expected breaking
> changes.
They *are* going away, and we've had no compunction about killing them
and updating the demo/test pages so far. Once we "pref on" (as google
is), the bar will be higher, but we will continue to track the spec and
will not support deprecated APIs for a long period (if at all). We even
have API check code on the WebRTC landing page to determine what API
your browser has and warn you if it's old or incompatible with the
current tests.
>> * 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).
>
> Again, if previous versions never go away, the spec should just define
> them all instead of pretending that the old versions went away. But
> see also http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
> and http://robert.ocallahan.org/2008/01/http-equiv_22.html .
>
> OTOH, if the plan is that old versions go away, how do you ensure that
> developers of Web apps are on board with tracking the API breakage? So
> far, telling Web devs that an API is subject to change has never
> avoided breakage.
Well, the biggest reason is that these aren't random web devs, these
devs are much more involved in the mailing lists and used to
standards-body tracking (lots of IETF/VoIP people, and people used to
dealing with IETF drafts changing during development). We have lots of
contact with them via the various mailing lists and are using G+,
webrtc.org and our test landing page on github to inform them and move
them forward. Some demos will be abandoned, but that's ok.
> In any case, both Firefox and Chrome supporting RTCPeerConnection00
> makes the API more compatible across browsers than Firefox supporting
> mozRTCPeerConnection and Chrome supporting webkitRTCPeerConnection, so
> I don’t see the WebRTC scenario as being an argument *for* *prefixes*
> even though I see WebRTC *might* be an argument *against* refraining
> from shipping experimental features on the release channel.
The biggest problem here (aluded to above) is that the API is broad
enough and progress by the two sides uneven enough that we haven't ever
had a converged API we could both support yet. We are moving towards
that (at least demos of interop calls), but even those will be done
partially by polyfill and maybe some wireline protocol adapters
temporarily. (Getting ICE (NAT traversal) to be compatible, for example.)
>> 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.
>
> Polyfills work when the person writing a polyfill for an API knows
> what the API will be and has a browser that already implements the API
> to test with so that the polyfill developer can be test with a real
> host browser that the polyfill really moves out of the way when the
> API is supported by the browser.
>
> You can't avoid future breakage with polyfills in the scenario where
> you assume that the APIs you currently know will go away and you don't
> yet know what they will be replaced with.
Polyfills here reduce the pain and breakage, but may not fully eliminate
it, and that's probably ok for this audience.
>> 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...).
>
> Why does the draft differ from what Chrome does? Is the difference
> worth all the versioning trouble? That is, why not make Chrome’s
> behavior the standard if Chrome already has the code that behaves like
> that (be definition) and we value (according to what you said)
> compatibility with Chrome?
Because we find areas where the draft doesn't cover the problemset well,
or areas that we've waved hands at in the draft and now get defined.
Chrome's impl roughly matches a version of the draft, but not
necessarily the current version (Chrome takes time to get to release, or
even Beta), but that's not a final draft. Random example: the stats API
is still in the proposal stage (and bouncing back and forth between IETF
and W3), and getting significant feedback from IETF and from developers
looking at it. The Bandwidth interaction API is still merely a proposal
I made in a W3 bug (repeatedly), though we need an API there to meet the
requirements. And there was considerable discussion of "rehydration" at
IETF: how to handle one side reloading the page in the middle of a call
(often done in web-apps when something "bad" happens in the hope of
resetting state to a sane place, or by accident by the user).
>> I wish I had a magic answer that would get the spec finished before
>> anyone ships this, but that's not happening. Sorry.
>
> To me, this says that either you will break Web apps or you will end
> up supporting all the API revisions that were ever shipped (or no one
> ended up using the API before it changed).
We will break webapps where we have to (and they'll generally know about
it ahead of time).
> If the plan is to support
> all the API revisions that ever got shipped, the solution is not to
> pretend that the later revisions replace old APIs and instead make the
> spec grow with side-by-side API alternatives. If the plan is to remove
> old API versions, who is the expected user of the APIs that will get
> broken?
Generally telecom providers, SBC (Border Controllers aka Gateways), some
people making frameworks, and people using getUserMedia to do
photobooth/etc type demos/apps. Most are just experimenting with it
currently as a sideline to their current products based on Flash, VoIP,
or plugins.
> Are the expected users really up to the task of changing their
> Web apps to track changing API versions so that browser end users
> don’t experience breakage?
Generally yes.
> Either way, a moz prefix won’t help. (It’s worthless as a “this will
> break” signal.)
Agreed. That's why I like suffixes.
> If the in-flux APIs are shipped only to be used by Google+, Facebook
> and a Skype Web app, expecting the Web devs to track API changes might
> be realistic. If the expected users are Web developers in general, I
> think it's completely unrealistic to expect them to track API changes.
Understood. We're in-between, but the devs using them generally are
reasonably able to track (if they can key off something). The only ones
likely to really break are small getUserMedia() demos.
> If the idea is to ship something that we know is going to change on
> the assumption that it will be used only by the likes of Google,
> Facebook or Skype, the right solution might be shipping the APIs,
> continue to break the APIs and have the APIs work only one short white
> list of domains whose dev teams are believed to be up to the task of
> tracking in-flux APIs (to prevent devs who aren’t up to the task from
> writing apps that depend on stuff we still want to break).
It's too large and dynamic a list for that. There are a LOT of people
experimenting with them and making demos and proof-of-concept apps.
They generally all have to follow either rtcweb (IETF), public-webrtc
(W3), or discuss-webrtc (generic group for devs to ask questions) - or
all three (though reading all three is a job in itself...).
I don't believe we have a perfect (or even a great) answer here. I
think suffixes would still be good to have until the API stabilizes. I
like suffixes a lot more as a general concept then vendor prefixes for
DOM APIs.
I'd love a magic wand to wave and finish the spec for us, leaving only
implementation, but it's a feedback circle between implementation and
spec for a while, and a time issue to hammer out the smaller items like
stats, resolution control, what a JS app is allowed to change in JSEP
offers/answers, exact constraint lists, etc.
And I believe WebRTC is a bit (or more) of a special case, with a huge
exposed surface and tons of detail being created for it in the IETF. No
other single feature I expect to see in the next many years is likely to
be as large.
--
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
