- 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