Section 11.3: RTCDataChannel: Promise send

[aboba]

Section 11.3 of the current editor's draft has:

partial interface RTCDataChannel : EventTarget {
Promise send (DOMString data);
Promise send (Blob data);
Promise send (ArrayBuffer data);
Promise send (ArrayBufferView data);
}

There is a known bug where send can block for substantial time. However, if this bug is fixed, It is not clear that a Promise is needed. Can we remove this?

[martinthomson]

What do you do when your peer's receive window is closed? Wouldn't it be nice to learn when the packets were committed to the network? (Or is this a promise that is fulfilled when the packets are acknowledged?)

[robin-raymond]

We had used promise for the sake of delivery verification (as well as better 'write driven' streaming) but the issue is that this deficiency in DataChannel is not our "problem" to fix. Justin pointed out that we should request that the original Data Channel spec writers to fix the problem in WebRTC and then we adopt the fix instead of possibly forking our own solution to the problem which might be different than there solution...

[martinthomson]

The problem with using acknowledgements is that it encourages a lock-step approach, which is grossly inefficient. Fulfilling the promise when the bytes have hit the network is probably useful information, because then you don't end up with a backlog of unsent messages.

I can appreciate Justin's concern here, and think that we do need to fix the API elsewhere as well. Perhaps this can be categorized with the bugs that ORTC is going to let someone else handle.

[aboba]

Agree that this probably should be classified as a "WebRTC 1.0 synchronization issue", with Section 11 (Data Channel) synchronizing with whatever ends up in WebRTC 1.0.