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