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:[email protected]] 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; [email protected] Subject: RE: [streams-api] Seeking status of the Streams API spec From: Aaron Colwell [mailto:[email protected]] > 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); }; 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.
