- From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
- Date: Wed, 05 Feb 2014 07:16:34 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Web-rtc <public-webrtc@w3.org>
- Message-ID: <52F1D742.1000702@omnitor.se>
On 2014-02-04 22:52, Martin Thomson wrote: > On 4 February 2014 11:40, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: >> If an application opens a data channel and requests the unreliable type with >> maximum 7 retries. >> And it turns out that the reliable type by default makes maximum 5 retries. > All I was looking for was that default == maximum. > > What we do if someone asks for more than the maximum is a separate > question. I'm OK with clamping down to the supported maximum if more > are requested, but given recent ...erm ...discussions, that might not > be an uncontroversial position. Yes. The more important points are not solved yet in my proposal. That is to get a full description of what happens in the API in failure situations on the sending side and on the receiving side. In some situations there are callback events, in others not. And some parameter should be provided in the callback about the reason. This is as far as I commented on this part of the topic: --------------------------------------------------------------------------------- 4. More general information about failures should be provided. Proposal to add one more sentence in the same paragraph: "The status of the PeerDataConnection is also monitored through heartbeats, and lack of a number of heartbeats from the peer, or closing of other channels in the PeerDataConnection or other failure indications will cause the connection to be teared down. The status of the transmission at the time of failure can be interrogated in the transmit buffer as described by the BufferedAmount attribute." 5. Details in the API description. The indications about the functionality described above and suggested to the paragraph in 5.2, then needs to be detailed in the API descriptions elsewhere in chapter 5, mainly in the parameters of the onerror and onclose events in 5.3 -------------------------------------------------------------------------------------- I can start proposing details, but wanted to see if there was agreement to do this first. Thanks, Gunnar
Received on Wednesday, 5 February 2014 06:17:07 UTC