- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 27 Mar 2014 08:51:07 +0100
- To: public-webrtc@w3.org
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.
>
--
Surveillance is pervasive. Go Dark.
Received on Thursday, 27 March 2014 07:51:36 UTC