Re: WebRTC and backpressure (how to stop reading? And how to start sending again?)

I did not read all the thread but it seems that Nicholas is raising 
excellent points.

My overall feeling about the situation is summarized here: 
http://lists.w3.org/Archives/Public/public-html-media/2014Mar/0053.html 
--> absurd

As you can guess my current project is moving to webRTC.

I think all groups should straight away start integrating whatwg/w3c 
streams instead of doing custom made implementations that will not work, 
ignoring the evidence and repeating the errors of the past, backpressure 
and handling of delta data (to turn them into a stream) are essential.

Regards

Aymeric

Le 26/03/2014 23:53, Domenic Denicola a écrit :
> Hi all, and thanks to Nicholas for bringing me into this conversation.
>
>> The required changes for the JavaScript spec would be the addition of a single `setReadEnabled(bool)` method or a settable attribute on RTCDataChannel.
> I agree that a `setReadEnabled(boolean)` API would be perfect for adding backpressure to the read side (for both web sockets and WebRTC). From what I can tell, that would suffice to allow wrapping WebRTC data channels into standard WHATWG stream interfaces, with backpressure, and thus letting them participate in our (very nascent) browser stream ecosystem.
>
> This is basically the lowest-level API that can work, which IMO is a good thing.
>
>> On way would be to have an event signalling "you can read some data now if you have time" instead of "here's some data, deal with it"
> In our experience in Node.js streams, which inform WHATWG streams heavily, this is the most friendly user interface: the ability to read data at will until there is none left in the buffer, combined with a notification when the buffer transitions from empty to non-empty. In fact, it is precisely this interface WHATWG streams present:
>
> ```js
> while (readableStream.state === "readable") {
>    console.log(readableStream.read());
> }
>
> // Assuming the stream didn't signal closure, and there were no errors, we now have:
> assert(readableStream.state === "waiting");
>
> // Get notified when there is more data (or the stream decides to asynchronously close/error)
> readableStream.wait().then(() => {
>    assert(readableStream.state === "readable" || readableStream.state === "closed");
> }, e => {
>    assert(readableStream.state === "errored");
>    console.error(e);
> });
> ```
>
> Whether WebRTC wants to present something like this is up to you guys, but my gut instinct is that `setReadEnabled` is sufficient for now, and later perhaps we can consider using true standard streams for WebRTC instead of "streams-inspired" interfaces. In the meantime, `setReadEnabled` would allow users to experiment with wrapping WebRTC into a standard stream.
>
>> Other designs could be to tweak onmessage so that if the EventHandler returns false, onmessage isn't fired again until a `resumeReading()` method is called.
> This seems strictly less powerful than `setReadEnabled`, since it basically says you can only pause via return value of an event handler.
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Received on Wednesday, 26 March 2014 23:27:38 UTC