Streams provide a JS primitive for accessing incremental, streamed data. For example, the fetch Response object can expose a body ReadableStream which allows reading a potentially infinite http response. Currently the only way to do something like this is with XMLHttpRequest with the append extension. Unfortunately that still requires keeping the entire resource in memory as data is appended. Streams do not have this limitation.
Chrome has shipped the fetch Response.body stream, but not the rest of the API. I spent time evaluating this spec over the last few months. I put the findings from that eval in a blog post here: https://blog.wanderview.com/blog/2015/06/19/intent-to-implement-streams-in-firefox/ There were three main concerns for which I believe we now have consensus on how to move forward: 1) Possible performance issues with the async read() function. 2) Operating on public functions can preclude optimizations like off-main-thread copying of streams. 3) Streams need to support transfer between threads. These are discussed more fully in the blog post linked above. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1128959 Standard: https://streams.spec.whatwg.org/ Platforms: All ETA: Initial implementation of Response.body stream in by end of 2015. Full spec in first half 2016. Pref: TBD (depends on if DOM or jsapi self-hosted) devtools: TBD as its unclear what additional features devtools would need for Streams. Please let me know if there are any questions or concerns. Thank you! Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
