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>
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 Fax: (425) 936-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
> 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]
> 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
> Subject: RE: [streams-api] Seeking status of the Streams API spec
>
> From: Aaron Colwell [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.
>
>