Also, I have setup a session on streams in the DOM room at Whistler:
http://juneworkweekwhistler2015.sched.org/event/28ff926a768953ba39a44cd36598d7f7 Please stop by if you have questions or just want to talk about it. Thanks! Ben On Fri, Jun 19, 2015 at 2:00 PM, Benjamin Kelly <[email protected]> wrote: > 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 [email protected] https://lists.mozilla.org/listinfo/dev-platform
