Re: Issue 598: Sender.setTransport a promise due to async issues?

[BA] Currently, the error conditions being checked for include:


1.     If receiver.stop() has been called, return p rejected with InvalidStateError.

2.     If setTransport() is called with no arguments, or if withTransport is unset, return p rejected with InvalidParameters.

3.     If withTransport.transport.component is RTCP, return p rejected with InvalidParameters.

4.     If withRtcpTransport is set and withRtcpTransport.transport.component is RTP, return p rejected with InvalidParameters.

5.     If withTransport.state is closed or failed, return p rejected with InvalidState.

6.     If withRtcpTransport.state is closed or failed, return p rejected with InvalidState.

If we were to remove checks 5 and 6, then this would remove any dependency on DtlsTransport.state.  This would enable setTransport to replace the existing transports with ones that are closed/failed.  But presumably the application would realize this when transport.onstatechange or rtcpTransport.onstatechange event handlers indicate a transition to the "closed" or "failed" state.  So the error would occur in only one place.

Shijun Sun replied:

"sender.setTransport should not have dependency on the state of the transport, which is expected to change dynamically. We should not expect setTransport to throw exception, therefore there is no need to change the call to promise-based. It should be kept consistent with the sender constructor logic.
The (proposed) promise could make the app more complicated if there are two places to handle the transport.state. Handling the transport object with the transport.onstatechange should be sufficient.
"


Robin Raymond said:

"It's possible that the transport passed into sender.setTransport dies just moments before the setTransport is called unknown to the app developer (e.g. DTLS asynchronously failed to negotiate). Thus the setTransport would throw an exception because the passed in transport is dead. The programmer would NOT have received the transport state change and thus would be unaware anything went wrong in advance and could not substitute an alternative transport before the promise is fulfilled upon receiving the state change event (and thus disregard any setTransport exceptions due to failed states that are not relevant)."