On Sep 3, 2014, at 6:02 PM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: > > The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe just expect streams to land in the right place in the APIs when they are available, by some unknown magic. I care about it. Till the API is totally baked, I’m amenable to getting the model right. File API now refers to chunks read, which is more correct. But I understand that your use cases aren’t catered to just yet; FileReader/FileReaderSync don’t do easily extractable partials. I’d like to see if there’s interest in the earlier proposal, to extract a stream straight from Blob. > > I still think that the effort should start from now for all the APIs (as well as the implementation inside browsers, which apparently has started for Chrome, but Chrome was supposed to have started some implementation of the previous Streams APIs, so it's not very clear), and that it should be very clearly synchronized, disregarding vague assumptions from the groups about low/high level and Vx releases, eluding the issue. What issue is being eluded? Seems like another of your main use cases is to have URL.createObjectURL or URL.createFor return a streamable resource. I agree that’s a good problem to solve. — A*
Received on Thursday, 4 September 2014 00:40:06 UTC