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

It's here https://github.com/whatwg/streams

It's a "merge" of WHATWG/W3C Streams specs taking large inspiration of 
node's streams.

There are still some open questions but I think all groups related to 
streams should start integrating this from now.

Regards

Aymeric

Le 27/03/2014 08:51, Harald Alvestrand a écrit :
> Domenic, can you please supply pointers to the actual WHATWG specs
> you're referring to?
>
> Especially the word "stream" has been used in so many conflicting ways
> by different specs over the years that I refuse to comment on proposals
> that refer to "stream" without a document reference.
>
> Sorry 'bout that....
>
> On 03/26/2014 11:53 PM, Domenic Denicola wrote:
>> 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 Thursday, 27 March 2014 08:11:48 UTC