Error handling

Annirudh raised a number of good questions about the specification.

This points to a greater concern: the level of consideration given to
error handling is probably inadequate.

·            For RTCConnection, should there be an ‘onerror’ event too ?

[MT] I should think so.  At some point, it makes sense to report that
we are no longer able to proceed.  With trickle ICE, this relies on a
signal that there are no more candidates forthcoming.  Of course, this
is a network, and things change, but we do want to be able to build
user-level feedback into applications.

·            For RTCConnection.connect/close, once an established
connection is closed by user and  later if they try to connect again,
should the process start from scratch like exchanging track
information etc. or try to re-establish connection with available data
?

[MT] I'd like to see RTCConnection be a one-use object.  Reusing
objects tends to make code more brittle.  GC is cheap enough.

·            For RTCCOnnection.removeStream, should the linked
RTCTracks be stopped and removed too if this stream is the only stream
they are linked to?

[MT] I would hope that removing streams only disconnects them from
consideration.  Note that stopped tracks cannot be restarted.

·            For RTCTrack, should there be a ‘pause’ method too ?

[MT] There is an enabled property on the MediaStreamTrack.  While my
preference is for an explicit pause()/resume() on network
transmission, I believe that other groups are tending toward the use
of enabled=true/false for this purpose.

·            For RTCTrack.remove(), how should the track be
‘un-removed’ or perhaps enabled again if the user wishes to ?

[MT] I don't like this concept much, so I'm not going to comment further :)

Received on Monday, 21 October 2013 18:24:22 UTC