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

On Tue, Oct 14, 2014 at 9:19 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Aaron Colwell [mailto:acolwell@google.com]
>
> > Yes SourceBuffer is shipping and has been for quite some time in Chrome
> and IE.
>
> Hmm, window.SourceBuffer is undefined in Chrome.
>

You can only create SourceBuffer objects via the MediaSource object. That
is why it isn't available on window.


>
> > I am NOT going to rework it all to be a WritableStream.
>
> That's a shame, but completely understandable that you wouldn't want to be
> one of the early-adopters. Over time we'll work to convert to using streams
> (in an integrated way) across the ecosystem, but I understand this will
> involve a lot of legwork from my side and from the streams implementers
> (e.g. the Tokyo team at Google).
>

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.


>
> > I am just looking to adjust appendStream() to take whatever object
> replaced the old Stream object that was in the original. It sounds like
> this is ReadableStream so I'll take a look at the latest spec text and
> update MSE accordingly.
>
> I would suggest just removing appendStream, personally. It does not seem
> to carry its own weight given that it is non-compositional with the rest of
> the stream ecosystem. As an analogy, this would be like adjusting a
> callback-taking method to wait for any promises its callbacks return,
> without actually converting the method to be promise-returning. In other
> words, a very halfhearted integration of a less-important part of the
> promise ecosystem, ignoring the more important part that allows developers
> to use the method seamlessly.
>

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.


>
> It would be better to wait for a "v2" of MSE that can integrate streams
> more correctly, than to tack on appendStream, IMO.
>
>
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.

Aaron