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.
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)?
