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 +0000 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 +0000 Resent-From: <public-webapps@w3.org> Date: Thu, 6 Feb 2014 20:31:18 -0800 From: ext Feras Moussa <feras.mou...@hotmail.com> To: public-webapps@w3.org <public-webapps@w3.org> CC: dome...@domenicdenicola.com <dome...@domenicdenicola.com>, Takeshi Yoshino <tyosh...@google.com> Hi All, I wanted to update everyone on the latest plan for moving forward on the Streams spec. For a variety of reasons, there are currently two Streams Specs being worked on - one in the W3C, and one in the WHATWG. Each of these specs have their strengths and weaknesses, and were looking at problems from different perspectives. After meeting with the WHATWG folks and discussing the various scenarios being targeted by the Streams specs as well as other considerations, we all agreed that we have the same goals and should work together to get alignment and avoid having different implementations. This is an opportunity to get a strong consistent API which behaves similarly across the various platforms, from browsers to servers. We are excited with the potential here, because it lets us tell one story. Moving forward, we've agreed to revise the approach to working on the Streams spec as follows: Create a 'base' Stream spec, which we will work together on. This will be seeded with the base of the WHATWG spec, and we will incorporate various pieces from either spec as needed. This base Stream should: 1. Be the lowest primitive that is independent of any platform 2. Be a layer that could make it into the JS language/ES 3. Could be prototyped in JavaScript directly to showcase it 4. Supports the various Stream goals we discussed, such as creation, backpressure, read/write behaviors, etc. 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. Once we've reorganized the components as defined above, we will share out further details for locations of the specs as well as solicit review. Thanks, Feras
