- From: Nils Ohlmeier via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Feb 2018 00:38:45 +0000
- To: public-webrtc-logs@w3.org
After talking to @jan-ivar to this is it turns out that my suggestion is not a good idea from an API's perspective. In the _RTCDataChannelEvent_ event handler is the first time you get a reference to a newly created channel. Thus this is also the first time you can install an _onopen_ callback on the new channel. But in the scenario where the underlying transports are connected already if we then start any new channel in _open_ right away, every user of the API would have to have an if condition in the _ondatachannel_ event handler distinguishing between the first and all subsequent channels. So for the purpose of having a consistent API which always behaves the same it seems a new channel in the _RTCDataChannelEvent_ should always start in the 'connecting' state, so that you can always setup an _onopen_ callback, which executes always the same code no matter what the initial state of the underlying transports is/was. But that means that we would have to remove the concept of 'underlying transport' from a couple of place in the data channel sections. -- GitHub Notification of comment by nils-ohlmeier Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1761#issuecomment-364297317 using your GitHub account
Received on Friday, 9 February 2018 00:38:48 UTC