Re: [streams-api] Seeking status of the Streams API spec
On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised via [1] (or [2] if applicable). -AB [1] https://www.w3.org/Bugs/Public/buglist.cgi?component=Streams%20APIlist_id=46026product=WebAppsWGresolution=--- [2] https://github.com/whatwg/streams/issues
Re: [streams-api] Seeking status of the Streams API spec
- annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus... cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: [streams-api] Seeking status of the Streams API spec
On Oct 23, 2014, at 15:10 , cha...@yandex-team.ru wrote: - annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus… well, they do and they don't editor’s drafts do not reflect consensus of any kind working drafts (roughly) reflect where the WG thinks it is, not all of which is done or has consensus (in terms of content), but it does have consensus that the draft reflects the WG's current ‘best thinking’ cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com David Singer Manager, Software Standards, Apple Inc.
RE: [streams-api] Seeking status of the Streams API spec
Separate from heartbeat publication, we don't believe it is appropriate to directly reference this spec in MSE until some questions are answered about how streams will be represented. Jerry -Original Message- From: David Singer [mailto:sin...@apple.com] Sent: Thursday, October 23, 2014 6:26 AM To: cha...@yandex-team.ru Cc: Paul Cotton; Takeshi Yoshino; Jerry Smith (WINDOWS); public-webapps; public-html-me...@w3.org Subject: Re: [streams-api] Seeking status of the Streams API spec On Oct 23, 2014, at 15:10 , cha...@yandex-team.ru wrote: - annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus... well, they do and they don't editor's drafts do not reflect consensus of any kind working drafts (roughly) reflect where the WG thinks it is, not all of which is done or has consensus (in terms of content), but it does have consensus that the draft reflects the WG's current 'best thinking' cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com David Singer Manager, Software Standards, Apple Inc.
Re: [streams-api] Seeking status of the Streams API spec
Hi Arthur, OK. Since I hurried, there're some odd texts left. Fixed: https://dvcs.w3.org/hg/streams-api/rev/891635210233 On Tue, Oct 21, 2014 at 10:53 PM, Arthur Barstow art.bars...@gmail.com wrote: On 10/14/14 11:06 PM, Takeshi Yoshino wrote: 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. Takeshi - given the magnitude of the changes in [changeset], a new WD should be published. I'll start a related PSA targeting a publication on October 23. (I'll start working on the draft WD if you don't have the time.) -Thanks, AB [changeset] https://dvcs.w3.org/hg/streams-api/rev/e5b689ded0d6
RE: [streams-api] Seeking status of the Streams API spec
given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. /paulc HTML WG co-chair [1] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0206.html Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Wednesday, October 22, 2014 8:38 AM To: Arthur Barstow Cc: Paul Cotton; Jerry Smith (WINDOWS); Anne van Kesteren; public-webapps; Feras Moussa; public-html-me...@w3.org; Domenic Denicola; Aaron Colwell Subject: Re: [streams-api] Seeking status of the Streams API spec Hi Arthur, OK. Since I hurried, there're some odd texts left. Fixed: https://dvcs.w3.org/hg/streams-api/rev/891635210233 On Tue, Oct 21, 2014 at 10:53 PM, Arthur Barstow art.bars...@gmail.commailto:art.bars...@gmail.com wrote: On 10/14/14 11:06 PM, Takeshi Yoshino wrote: 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. Takeshi - given the magnitude of the changes in [changeset], a new WD should be published. I'll start a related PSA targeting a publication on October 23. (I'll start working on the draft WD if you don't have the time.) -Thanks, AB [changeset] https://dvcs.w3.org/hg/streams-api/rev/e5b689ded0d6
Re: [streams-api] Seeking status of the Streams API spec
On 10/14/14 11:06 PM, Takeshi Yoshino wrote: 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. Takeshi - given the magnitude of the changes in [changeset], a new WD should be published. I'll start a related PSA targeting a publication on October 23. (I'll start working on the draft WD if you don't have the time.) -Thanks, AB [changeset] https://dvcs.w3.org/hg/streams-api/rev/e5b689ded0d6
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:tyosh...@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-me...@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.cot...@microsoft.commailto:paul.cot...@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-9596tel:%28425%29%20705-9596 Fax: (425) 936-7329tel:%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-me...@w3.orgmailto:public-html-me...@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:dome...@domenicdenicola.commailto:dome...@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-me...@w3.orgmailto:public-html-me...@w3.org Subject: RE: [streams-api] Seeking status of the Streams API spec From: Aaron Colwell [mailto:acolw...@google.commailto:acolw...@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
RE: [streams-api] Seeking status of the Streams API spec
From: Paul Cotton [mailto:paul.cot...@microsoft.com] 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? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision.
RE: [streams-api] Seeking status of the Streams API spec
The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. This seems to contradict the direction that was published in Feb 2014 [1] in which it was clearly stated: In addition to the base Stream spec, the remaining platform-specific pieces which do not fit into the shared-base spec will live in an independent spec. This includes things such as support in other APIs (XHR, MediaStreaming, etc) or DOM specific scenarios - (createObjectURL()). The current W3C Streams API will focus on this aspect of the API surface, while leaving the core functionality to be defined in the base spec. It seems to me that layering a Stream interface in an independent spec would support other APIs like MSE. Why cannot this be done? /paulc [1] http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0218.html Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, October 15, 2014 2:25 PM To: Paul Cotton; Takeshi Yoshino Cc: Jerry Smith (WINDOWS); Anne van Kesteren; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.org; Aaron Colwell Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] 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? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision.
Re: [streams-api] Seeking status of the Streams API spec
On Wed, Oct 15, 2014 at 11:24 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Paul Cotton [mailto:paul.cot...@microsoft.com] 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? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision. This decision makes sense to me. I just need to sit down and read the new Streams spec to come up with a new proposal. The simplest solution looks like it would be to just change the Stream to ReadableStream in the existing appendStream() signature and then update the relevant algorithms to properly interact with that object. Like I said, I don't have enough knowledge yet to fully understand the implications of that yet. I plan to spend some quality time with the Stream spec sometime this week so I can get a better handle on this. I will probably have questions for Domenic and Takeshi, but I know where to find them. :) I believe the old Stream interface is only a problem for IE. I don't think any other browser has shipped it. While I am sensitive to the backwards compatibility issues, it isn't clear to me that we should stick to the old signature just because IE chose to ship a Stream object before the spec was in a more stable state. In some ways I feel like it is better that there are different object names because then this could just be handled like a method overload instead of trying to figure out how to distinguish 2 implementations with the same object name. Aaron
Re: [streams-api] Seeking status of the Streams API spec
On Mon, Oct 13, 2014 at 10:00 PM, Paul Cotton paul.cot...@microsoft.com wrote: MSE is in CR and there are shipping implementations. Yes, but the Stream object is not shipping. Unless Microsoft has a prototype it is in exactly 0 implementations. So MSE would have to get out of CR anyway to get that removed (assuming it's following the two implementation rule). -- https://annevankesteren.nl/
RE: [streams-api] Seeking status of the Streams API spec
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Mon, Oct 13, 2014 at 10:00 PM, Paul Cotton paul.cot...@microsoft.com wrote: MSE is in CR and there are shipping implementations. Yes, but the Stream object is not shipping. Unless Microsoft has a prototype it is in exactly 0 implementations. So MSE would have to get out of CR anyway to get that removed (assuming it's following the two implementation rule). The more interesting question is whether BufferSource is shipping (unprefixed), since ideally we would make BufferSource a WritableStream.
RE: [streams-api] Seeking status of the Streams API spec
From: Domenic Denicola [mailto:dome...@domenicdenicola.com] The more interesting question is whether BufferSource is shipping (unprefixed), since ideally we would make BufferSource a WritableStream. Sorry, SourceBuffer, not BufferSource---both in this message and the previous one.
Re: [streams-api] Seeking status of the Streams API spec
Yes SourceBuffer is shipping and has been for quite some time in Chrome and IE. Firefox and Safari have been working on implementations for quite some time as well. I am NOT going to rework it all to be a WritableStream. 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 believe IE is the only browser to have shipped an implementation of appendStream(). Chrome had an implementation, but it never made it out from behind a flag because the Streams spec got rebooted before it had a chance to ship. At least on the Chrome, side I know that we were waiting until the Stream spec changes actually settled down and became stable again before trying for another implementation. It sounds like we are at that point now. Aaron On Tue, Oct 14, 2014 at 1:00 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Domenic Denicola [mailto:dome...@domenicdenicola.com] The more interesting question is whether BufferSource is shipping (unprefixed), since ideally we would make BufferSource a WritableStream. Sorry, SourceBuffer, not BufferSource---both in this message and the previous one.
RE: [streams-api] Seeking status of the Streams API spec
From: Aaron Colwell [mailto:acolw...@google.com] Yes SourceBuffer is shipping and has been for quite some time in Chrome and IE. Hmm, window.SourceBuffer is undefined in Chrome. 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). 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. It would be better to wait for a v2 of MSE that can integrate streams more correctly, than to tack on appendStream, IMO.
Re: [streams-api] Seeking status of the Streams API spec
On Tue, Oct 14, 2014 at 9:19 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Aaron Colwell [mailto:acolw...@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
RE: [streams-api] Seeking status of the Streams API spec
From: Aaron Colwell [mailto:acolw...@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);
};
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.
RE: [streams-api] Seeking status of the Streams API spec
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/ .
/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-me...@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:dome...@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-me...@w3.org
Subject: RE: [streams-api] Seeking status of the Streams API spec
From: Aaron Colwell [mailto:acolw...@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);
};
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.
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.cot...@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-me...@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:dome...@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-me...@w3.org
Subject: RE: [streams-api] Seeking status of the Streams API spec
From: Aaron Colwell [mailto:acolw...@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.
RE: [streams-api] Seeking status of the Streams API spec
Good question. Takeshi should weigh in on this too since he has been doing some of the integration work. In general, the idea is for streams, like promises, to be a base primitive which many other specifications create instances of. Since the spec is focused on defining that primitive, it doesn't include an informative list of specs that could potentially use it; we left that for non-spec material. But in general the way we envision this working is much like with promises: new specs that include streaming data will reach around for the right primitive, and find streams; old specs that had their own custom stream-ish objects will over time upgrade; and all the while, developers will be prototyping and creating their own streams (some of which might wrap existing APIs) using the stream constructors. We as editors will be helping reach out and guide those efforts, as we've done with promises. Currently there are efforts ongoing with Fetch (XHR replacement) and Web Audio as the trailblazers, with more certainly to come. Hope that helps, -Domenic -Original Message- From: Paul Cotton [mailto:paul.cot...@microsoft.com] Sent: Thursday, October 9, 2014 19:04 To: Domenic Denicola Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec The previous W3C WD [1] identified a large number of specifications that were stream producers and consumers. Is there any kind of mapping of the interfaces in the previous W3C WD to your recent specification to give all of those other specifications some idea of how to change to align with the new Streams specification? /paulc HTML WG co-chair [1] http://www.w3.org/TR/2013/WD-streams-api-20131105/#producers-consumers Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Thursday, October 09, 2014 4:24 PM To: Paul Cotton Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] Was this Aug goal achieved? Yes: https://streams.spec.whatwg.org/
RE: [streams-api] Seeking status of the Streams API spec
old specs that had their own custom stream-ish objects will over time upgrade MSE [1] simply used the Stream object directly from the previous W3C WD [2]. Since this object no longer is available in [3], what you do recommend that MSE should do? /paulc [1] http://www.w3.org/TR/2014/CR-media-source-20140717/#sourcebuffer-stream-append-loop [2] http://www.w3.org/TR/2013/WD-streams-api-20131105 [3] https://streams.spec.whatwg.org/ Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Monday, October 13, 2014 2:40 PM To: Paul Cotton Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec Good question. Takeshi should weigh in on this too since he has been doing some of the integration work. In general, the idea is for streams, like promises, to be a base primitive which many other specifications create instances of. Since the spec is focused on defining that primitive, it doesn't include an informative list of specs that could potentially use it; we left that for non-spec material. But in general the way we envision this working is much like with promises: new specs that include streaming data will reach around for the right primitive, and find streams; old specs that had their own custom stream-ish objects will over time upgrade; and all the while, developers will be prototyping and creating their own streams (some of which might wrap existing APIs) using the stream constructors. We as editors will be helping reach out and guide those efforts, as we've done with promises. Currently there are efforts ongoing with Fetch (XHR replacement) and Web Audio as the trailblazers, with more certainly to come. Hope that helps, -Domenic -Original Message- From: Paul Cotton [mailto:paul.cot...@microsoft.com] Sent: Thursday, October 9, 2014 19:04 To: Domenic Denicola Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec The previous W3C WD [1] identified a large number of specifications that were stream producers and consumers. Is there any kind of mapping of the interfaces in the previous W3C WD to your recent specification to give all of those other specifications some idea of how to change to align with the new Streams specification? /paulc HTML WG co-chair [1] http://www.w3.org/TR/2013/WD-streams-api-20131105/#producers-consumers Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Thursday, October 09, 2014 4:24 PM To: Paul Cotton Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] Was this Aug goal achieved? Yes: https://streams.spec.whatwg.org/
RE: [streams-api] Seeking status of the Streams API spec
From: Paul Cotton [mailto:paul.cot...@microsoft.com] MSE [1] simply used the Stream object directly from the previous W3C WD [2]. Since this object no longer is available in [3], what you do recommend that MSE should do? OK, down to the fun stuff :). Here's my take based on some brief investigation... It depends on to what extent these MSE APIs are shipping and thus compatibility needs to be preserved. If they are shipping, something similar to appendStream seems OK: change it to take a ReadableStream and you'll be fine. However, BufferSource is basically a custom WritableStream instance, with many parallels I can outline if necessary. So ideally the related MSE APIs would be redesigned to either use a WritableStream directly, or to subclass it. That would be more idiomatic in how the streams ecosystem works, and in general would allow more compositional scenarios through the usual mechanisms (so that e.g. people could integrate the BufferSource writable stream into a generic stream pipeline, instead of special-casing how they handle it). I'd love to work with you or the editors on that, if there are no compat-constraints preventing it.
RE: [streams-api] Seeking status of the Streams API spec
It depends on to what extent these MSE APIs are shipping and thus compatibility needs to be preserved. MSE is in CR and there are shipping implementations. I'd love to work with you or the editors on that I have added public-html-me...@w3.org to this thread. /paulc Sent from my Windows Phone From: Domenic Denicola Sent: 13/10/2014 3:04 PM To: Paul Cotton; Takeshi Yoshino Cc: public-webapps; Arthur Barstow; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] MSE [1] simply used the Stream object directly from the previous W3C WD [2]. Since this object no longer is available in [3], what you do recommend that MSE should do? OK, down to the fun stuff :). Here's my take based on some brief investigation... It depends on to what extent these MSE APIs are shipping and thus compatibility needs to be preserved. If they are shipping, something similar to appendStream seems OK: change it to take a ReadableStream and you'll be fine. However, BufferSource is basically a custom WritableStream instance, with many parallels I can outline if necessary. So ideally the related MSE APIs would be redesigned to either use a WritableStream directly, or to subclass it. That would be more idiomatic in how the streams ecosystem works, and in general would allow more compositional scenarios through the usual mechanisms (so that e.g. people could integrate the BufferSource writable stream into a generic stream pipeline, instead of special-casing how they handle it). I'd love to work with you or the editors on that, if there are no compat-constraints preventing it.
RE: [streams-api] Seeking status of the Streams API spec
For concrete timeline: one of my Q3 goals as a Google employee is to publish a polished version of the stream spec + polyfill + test suite. This might be slightly optimistic but still seems doable. Was this Aug goal achieved? It does not look like the W3C Streams API WD has been updated since http://www.w3.org/TR/2013/WD-streams-api-20131105/ /paulc HTML WG co-chair Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, August 20, 2014 11:57 PM To: Arthur Barstow; Takeshi Yoshino; Feras Moussa Cc: public-webapps; team-html-cha...@w3.org Subject: RE: [streams-api] Seeking status of the Streams API spec Hi HTML WG, The streams API is progressing quite nicely, and is *very* close to being settled. At this point much of what remains is polishing the spec; the text is quite raw at the moment, with much of the trickier bits (e.g. transform streams) relegated to the reference implementation as we tweak the algorithms and add more to the test suite before porting them back into the spec proper. The spec work is happening at https://github.com/whatwg/streams; see also https://whatwg.github.io/streams/ (temporary URL) which contains more of the explanatory text and examples, and will eventually contain the algorithms currently prototyped at the former URL. There is a slight chance that some parts of the API may become a bit simpler over the next week. In particular I am investigating: (1) combining the async-notify + sync-read/write into async-read/write; and (2) possibilities for a design that makes readable and writable streams two sides of the same pipe, to simplify their construction APIs. However, neither of these is looking terribly fruitful or worthwhile right now, and in either case I have set myself a hard deadline of finishing that investigation and any related changes by next Friday before I leave for some travel. In terms of what's happening and what's coming: Chrome is prototyping an implementation at [1] (see also [2]). At [3], Takeshi has begun work on a simple extension for bring your own buffer binary streams that interoperate with the more generic streams that compose the bulk of the work done so far, which is looking lovely. The TCP/UDP sockets spec [4] has been based on this streams design for some time, and is seeing implementation interest at Mozilla in addition to very successful engagement from the editor of that spec in figuring out how to integrate streams there. For concrete timeline: one of my Q3 goals as a Google employee is to publish a polished version of the stream spec + polyfill + test suite. This might be slightly optimistic but still seems doable. I also know that Takeshi's team is hoping to have a prototype implementation in Blink somewhere near that timeframe as well, and is currently investigating fetch integration [5]. In any case, hope this is helpful and if you have any questions, feel free to reach out, either on the public-webapps or whatwg mailing lists, or (preferably) on our GitHub issue tracker. We really enjoyed the collaboration on TCP/UDP sockets and would be happy to do similar for Media Source Extensions. Best, -Domenic [1]: https://code.google.com/p/chromium/issues/detail?id=393911 [2]: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.h [3]: https://github.com/whatwg/streams/pull/173 [4]: https://github.com/sysapps/tcp-udp-sockets [5]: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0285.html -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Monday, August 18, 2014 14:28 To: Takeshi Yoshino; Feras Moussa; Domenic Denicola Cc: public-webapps; team-html-cha...@w3.org Subject: [streams-api] Seeking status of the Streams API spec Hi All, The HTML WG would like to know the status of the Streams API and if the February plan from Feras (see below) is still the plan-of-action. Please provide an update. Paul - the last status I saw was the following e-mail from Domenic on June 27 http://lists.w3.org/Archives/Public/public-sysapps/2014Jun/0014.html. -Thanks, AB Original Message Subject:RE: Update on Streams API Status Date: Mon, 18 Aug 2014 17:57:05 + From: Paul Cotton paul.cot...@microsoft.com To: Arthur Barstow (art.bars...@gmail.com) art.bars...@gmail.com, Charles McCathie Nevile (cha...@yandex-team.ru) cha...@yandex-team.ru CC: team-html-cha...@w3.org team-html-cha...@w3.org I am preparing a Media TF agenda and we still have a TF Action [1] open concerning coordination with WebApps WG on the Streams API. Can you point me to a more recent status report on the work on the Streams API spec(s) than the one below from Feb 2014? Was the plan in this update actually implemented? /paulc [1
RE: [streams-api] Seeking status of the Streams API spec
From: Paul Cotton [mailto:paul.cot...@microsoft.com] Was this Aug goal achieved? Yes: https://streams.spec.whatwg.org/
RE: [streams-api] Seeking status of the Streams API spec
The previous W3C WD [1] identified a large number of specifications that were stream producers and consumers. Is there any kind of mapping of the interfaces in the previous W3C WD to your recent specification to give all of those other specifications some idea of how to change to align with the new Streams specification? /paulc HTML WG co-chair [1] http://www.w3.org/TR/2013/WD-streams-api-20131105/#producers-consumers Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Thursday, October 09, 2014 4:24 PM To: Paul Cotton Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] Was this Aug goal achieved? Yes: https://streams.spec.whatwg.org/
RE: [streams-api] Seeking status of the Streams API spec
Hi HTML WG, The streams API is progressing quite nicely, and is *very* close to being settled. At this point much of what remains is polishing the spec; the text is quite raw at the moment, with much of the trickier bits (e.g. transform streams) relegated to the reference implementation as we tweak the algorithms and add more to the test suite before porting them back into the spec proper. The spec work is happening at https://github.com/whatwg/streams; see also https://whatwg.github.io/streams/ (temporary URL) which contains more of the explanatory text and examples, and will eventually contain the algorithms currently prototyped at the former URL. There is a slight chance that some parts of the API may become a bit simpler over the next week. In particular I am investigating: (1) combining the async-notify + sync-read/write into async-read/write; and (2) possibilities for a design that makes readable and writable streams two sides of the same pipe, to simplify their construction APIs. However, neither of these is looking terribly fruitful or worthwhile right now, and in either case I have set myself a hard deadline of finishing that investigation and any related changes by next Friday before I leave for some travel. In terms of what's happening and what's coming: Chrome is prototyping an implementation at [1] (see also [2]). At [3], Takeshi has begun work on a simple extension for bring your own buffer binary streams that interoperate with the more generic streams that compose the bulk of the work done so far, which is looking lovely. The TCP/UDP sockets spec [4] has been based on this streams design for some time, and is seeing implementation interest at Mozilla in addition to very successful engagement from the editor of that spec in figuring out how to integrate streams there. For concrete timeline: one of my Q3 goals as a Google employee is to publish a polished version of the stream spec + polyfill + test suite. This might be slightly optimistic but still seems doable. I also know that Takeshi's team is hoping to have a prototype implementation in Blink somewhere near that timeframe as well, and is currently investigating fetch integration [5]. In any case, hope this is helpful and if you have any questions, feel free to reach out, either on the public-webapps or whatwg mailing lists, or (preferably) on our GitHub issue tracker. We really enjoyed the collaboration on TCP/UDP sockets and would be happy to do similar for Media Source Extensions. Best, -Domenic [1]: https://code.google.com/p/chromium/issues/detail?id=393911 [2]: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.h [3]: https://github.com/whatwg/streams/pull/173 [4]: https://github.com/sysapps/tcp-udp-sockets [5]: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0285.html -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Monday, August 18, 2014 14:28 To: Takeshi Yoshino; Feras Moussa; Domenic Denicola Cc: public-webapps; team-html-cha...@w3.org Subject: [streams-api] Seeking status of the Streams API spec Hi All, The HTML WG would like to know the status of the Streams API and if the February plan from Feras (see below) is still the plan-of-action. Please provide an update. Paul - the last status I saw was the following e-mail from Domenic on June 27 http://lists.w3.org/Archives/Public/public-sysapps/2014Jun/0014.html. -Thanks, AB Original Message Subject:RE: Update on Streams API Status Date: Mon, 18 Aug 2014 17:57:05 + From: Paul Cotton paul.cot...@microsoft.com To: Arthur Barstow (art.bars...@gmail.com) art.bars...@gmail.com, Charles McCathie Nevile (cha...@yandex-team.ru) cha...@yandex-team.ru CC: team-html-cha...@w3.org team-html-cha...@w3.org I am preparing a Media TF agenda and we still have a TF Action [1] open concerning coordination with WebApps WG on the Streams API. Can you point me to a more recent status report on the work on the Streams API spec(s) than the one below from Feb 2014? Was the plan in this update actually implemented? /paulc [1] https://www.w3.org/html/wg/media/track/actions/59 Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Friday, February 07, 2014 7:58 AM To: public-html-ad...@w3.org Subject: Fwd: Update on Streams API Status Since the Media Source Extensions spec includes a normative reference for WebApps' Streams API, please see the following status and plans information from the spec's Editors. If you have any comments, please send them to mailto:public-webapps@w3.org. Original Message Subject:Update on Streams API Status Resent-Date:Fri, 7 Feb 2014 04:31:48 + Resent-From:public-webapps@w3.org Date:
