RE: Issue 148: Success & Failure Callbacks in RTCRtpSender.setTrack

Peter said: 

"If it could fail, then we'd need a callback.  If it can't, then we don't.  I'd prefer a Promise to two callbacks."

[BA] Right.  I also would prefer a Promise to two callbacks. 

With respect to failure scenarios, Martin noted that basic checks could be handled via Exception, without requiring a failure callback (e.g. see http://lists.w3.org/Archives/Public/public-webrtc/2014Sep/0011.html).  But there was a question of whether "confirming that a track is a compatible replacement" would require a failure callback.  Assuming that the replacement track is of the same kind, has the same peerIdentity constraint as the old one and is in the right state, is there something else that could go wrong that would only be determined later??  

Received on Wednesday, 3 September 2014 21:51:44 UTC