- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 03 Jan 2013 14:25:19 -0500
- To: public-webrtc@w3.org
Hi, I've been working with WebRTC for 1.5 months now using Chrome and I think one of the most frustrating things about the specification is poor handling of user errors. The specification needs to be a lot more strict with respect to catching user errors and when they occur providing a specific explanation of what went wrong. I'll provide one specific example which you can extrapolate to the rest of the API. I spent a couple of days trying to figure out why setRemoteDescription() was returning "SetRemoteDescription failed." It returns the same error if the PeerConnection state is wrong (user skipped an initialization step), or the description type is wrong ("answer" vs "offer") or even if you invoke it one too many times (I had it in a loop by mistake). Each error case should throw a different message. The message should indicate what went wrong and (if possible) how to fix it. Another source of frustration are "silent failures" as a side-effect of the asynchronous nature of the API. I've repeatedly run into cases where I was expecting an event to get fired but it never did. It's one thing for the API to return a vague error. It's even worse when it doesn't return an error at all and the application hangs. For example, I'm adding a remote stream is added to an autoplay <video> element (as seen in http://apprtc.appspot.com/) but for some reason nothing is happening. It looks like the video isn't being sent by the remote peer but the API provides no mechanism for debugging this because addStream() provides no events. I'm listening on all PeerConnection event listeners and see no obvious problem. I'm fairly certain this is a user error because http://apprtc.appspot.com/ runs fine on the same computer but my point is these kinds of problems should be easier to troubleshoot. Thanks for listening :) Gili
Received on Saturday, 5 January 2013 08:24:45 UTC