On 5/13/10 1:50 PM, J Ross Nicoll wrote:
On 13 May 2010, at 13:27, Arun Ranganathan wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that have
been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further binary data operations by exposing an ArrayBuffer property
that represents the Blob. ArrayBuffers, and affiliated "Typed Array" views of
data, are specified in a working draft as a part of the WebGL work [1]. This work has
been proposed to ECMA's TC-39 WG as well. We intend to implement some of this in the
Firefox 4 timeframe, and have reason to believe other browsers will as well. I have thus
cited the work as a normative reference [1]. Eventually, we ought to consider further
read operations given ArrayBuffers, but for now, I believe exposing Blobs in this way is
sufficient.
Why remove the 'type' attribute from the File? Specifically, is there a real
issue with duplicating the information in both the File and the Blob? Two main
concerns:
Without 'type' in the File attribute, you have to read the file to understand
what's in it. This means that if you want to, for example, produce a
confirmation dialogue for the user before reading a file, it's very limited in
how much information it can show (I also think it would be a good idea to have
'size' as an attribute on the File, for related reasons).
At the moment, if a directory is been dragged and dropped into Firefox, the
only way to spot this appears to be the 'type' attribute (which is empty).
Unless I'm missing something, as written this would appear to mean the JS has
to try reading a directory, get a Blob back (which Firefox does do, at least)
and then it can find out it didn't actually read a file.
Currently, File inherits from Blob.
Looking at synchronized file reading... would it perhaps make more sense to
have readAsBinaryString(), readAsText() and readAsDataURL() as methods on the
File, rather than a specific separate interface (FileReaderSync)?
FileReader is for asynchronous reads on the main thread. FileReaderSync
is for synchronous reads on worker threads. We want to:
1. Decouple Files from the objects that read from them and
2. Disallow any synchronous File I/O on the main thread.
-- A*
