- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Apr 2017 18:48:39 +0000
- To: public-webrtc-logs@w3.org
>> This API is more convenient to use from a web developer point of view for simple A/V calls then addTrack/ontrack. > Then write a library or some code which simplifies the API usage, but don't bloat the native API to support a simple and a more complex version. The point I was trying to make was just that web developers will not have a huge incentive to move towards addTrack given addStream is often more convenient. Contrary to callback/promise APIs. This might mean that addStream might remain in browsers for a long time. >> This API is available in Edge, Chrome and Firefox while addTrack is only supported in Firefox. > Then get the implementations which are lacking behind the spec to finally implement what the spec is and don't give them excuses to implement what ever they want. As a browser implementor, not shipping addStream might be a problem (currently under assessment in WebKit). As a browser implementor, implementing addStream without a spec or a path towards convergence is a problem. > I think the WebRTC specs are way to complex already. Adding sections about legacy stuff will only bloat them and cause confusion on what has to be implemented and what is available. How about you create a separate document/spec which describes the old, legacy APIs. Agreed on the complexity of the WebRTC spec. WebRTC is already describing some legacy APIs for which the migration path is already quite clear (callback to promise e.g.). It is not describing the single legacy API that has widespread use, unclear interoperability and unclear migration path. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1125#issuecomment-293989255 using your GitHub account
Received on Thursday, 13 April 2017 18:48:46 UTC