RE: [streams-api] Seeking status of the Streams API spec

> I replaced the W3C Streams API spec WD with a pointer to the WHATWG Streams spec and a few sections discussing what we should add to the spec for browser use cases.

This change means that the W3C Editor’s draft no longer defines the Stream interface as was previously supported.  Would it be feasible to resurrect this interface as a layer on top of [1] so that W3C specifications like MSE that have a dependency on the Streams interface are not broken?

/paulc

[1] https://github.com/whatwg/streams


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Tuesday, October 14, 2014 11:06 PM
To: Paul Cotton
Cc: Jerry Smith (WINDOWS); Anne van Kesteren; public-webapps; Arthur Barstow; Feras Moussa; public-html-media@w3.org; Domenic Denicola; Aaron Colwell
Subject: Re: [streams-api] Seeking status of the Streams API spec

Re: establishing integration plan for the consumers and producers listed in the W3C spec, we haven't done anything than what Domenic introduced in this thread.

I wrote some draft of XHR+ReadableStream integration spec and is implemented on Chrome, but the plan is not to ship it but wait for the Fetch API as discussed at WHATWG.


On Wed, Oct 15, 2014 at 9:10 AM, Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>> wrote:
This thread was recently re-started at http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0084.html


Domenic's latest document is at https://streams.spec.whatwg.org/  The W3C document has NOT been updated since http://www.w3.org/TR/2013/WD-streams-api-20131105/ .

Not to confuse people, too late but I replaced the W3C Streams API spec WD with a pointer to the WHATWG Streams spec and a few sections discussing what we should add to the spec for browser use cases.


/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596<tel:%28425%29%20705-9596> Fax: (425) 936-7329<tel:%28425%29%20936-7329>


-----Original Message-----
From: Jerry Smith (WINDOWS)
Sent: Tuesday, October 14, 2014 8:03 PM
To: Domenic Denicola; Aaron Colwell
Cc: Anne van Kesteren; Paul Cotton; Takeshi Yoshino; public-webapps; Arthur Barstow; Feras Moussa; public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: RE: [streams-api] Seeking status of the Streams API spec

Where is the latest Streams spec?  https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm doesn't have much about WritableStreams.

Jerry

-----Original Message-----
From: Domenic Denicola [mailto:domenic@domenicdenicola.com<mailto:domenic@domenicdenicola.com>]
Sent: Tuesday, October 14, 2014 10:18 AM
To: Aaron Colwell
Cc: Anne van Kesteren; Paul Cotton; Takeshi Yoshino; public-webapps; Arthur Barstow; Feras Moussa; public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: RE: [streams-api] Seeking status of the Streams API spec

From: Aaron Colwell [mailto:acolwell@google.com<mailto:acolwell@google.com>]

> MSE is just too far along, has already gone through a fair amount of churn, and has major customers like YouTube and Netflix that I just don't want to break or force to migrate...again.

Totally understandable.

> I haven't spent much time looking at the new Stream spec so I can't really say yet whether I agree with you or not. The main reason why people wanted to be able to append a stream is to handle larger, open range, appends without having to make multiple requests or wait for an XHR to complete before data could be appended. While I understand that you had your reasons to expand the scope of Streams to be more general, MSE really just needs them as a "handle" to route bytes being received with XHR to the SourceBuffer w/o having to actually surface them to JS. It would be really unfortunate if this was somehow lost in the conversion from the old spec.

The way to do this in Streams is to pipe the fetch stream to a writable stream:

    fetch(url)
      .then(response => response.body.pipeTo(writableStream).closed)
      .then(() => console.log("all data written!"))
      .catch(e => console.log("error fetching or piping!", e));

By piping between two UA-controlled streams, you can establish an off-main-thread relationship between them. This is why it would be ideal for SourceBuffer (or a future alternative to it) to be WritableStream, especially given that it already has abort(), appendBuffer(), and various state-like properties that are very similar to what a WritableStream instance has. The benefit here being that people could then use SourceBuffers as generic destinations for any writable-stream-accepting code, since piping to a writable stream is idiomatic.

But that said, given the churn issue I can understand it not being feasible or desirable to take that path.

> Perhaps, although I expect that there may be some resistance to dropping this at this point. Media folks were expecting the Streams API to progress in such a way that would at least allow appendStream() to still work especially since it only needs a stream for recieving bytes. I'll dig into the latest Streams spec so I can better understand the current state of things.

One speculative future evolution would be for SourceBuffer to grow a `.stream` or `.writable` property, which exposes the actual stream. Then appendStream could essentially be redefined as

    SourceBuffer.prototype.appendStream = function (readableStream) {
      readableStream.pipeTo(this.writable);
    };

Needs porting some part of "Prepare Append Algorithm" in order not to run two or more pipeTo at the same time?

and similarly appendBuffer could be recast in terms of `this.writable.write`, etc. Then developers who wish to treat the SourceBuffer as a more generic writable stream can just do `myGenericWritableStreamLibrary(mediaSource.sourceBuffers[0].writable)` or similar.