- From: Philip Jägenstedt via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Apr 2017 17:30:24 +0000
- To: public-webrtc-logs@w3.org
Thanks @youennf, grouping all the legacy APIs behind one flag probably makes sense, this way we will not end up with (say) all engines supporting everything except WebKit for one or two tiny bits. That'd be a frustrating outcome for interoperability. > addStream/onaddstream seem widely used and might be the most problematic to not ship. >From a web developer point of view, addStream is also much more convenient than addTrack for simple cases. Sadly, addStream/onaddstream are not described anywhere Yep, this is a problem. Tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=697059 for Chromium. > As of testing, WebKit is trying to only use the latest API for its layout tests. > A few tests are dedicated to the legacy API. > I guess WPT tests could follow the same pattern. Yep, writing all tests using the new APIs except a few specifically targeting the old APIs makes sense. Unfortunately, the tests would become more convoluted when not having the APIs at all should also pass. Concretely, I think the only way to turn https://jsbin.com/coqibewate/edit?html,output into a per-spec test for createOffer would be to just pass the test where it would otherwise timeout, but that'd make real regressions invisible. AFAIK, there's no mechanism in web-platform-tests to mark a test as optional, or making the pass condition be implementation-defined so that regressions cannot go unnoticed. > Currently some webrtc tests are using unspecified APIs such as addStream... Filed https://github.com/w3c/web-platform-tests/issues/5533 -- GitHub Notification of comment by foolip Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1086#issuecomment-293336589 using your GitHub account
Received on Tuesday, 11 April 2017 17:30:31 UTC