W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 3 Sep 2014 20:39:34 -0400
Cc: Anne van Kesteren <annevk@annevk.nl>, Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>, Joshua Bell <jsbell@google.com>
Message-Id: <977691D4-65A0-4175-A5B3-B74905AAAF79@mozilla.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC