Re: Updates to File API

On 5/18/10 2:35 PM, Eric Uhrhane wrote:
> On Mon, May 17, 2010 at 3:37 PM, Dmitry Titov<dimich@chromium.org>  wrote:
>    
>> I have couple of questions, mostly clarifications I think:
>> 1. FileReader takes Blob but there are multiple hints that the blob should
>> be actually a 'file'. As we see Blob concept grows in popularity with such
>> specs as FileWriter that defines BlobBuilder. Other proposals include Image
>> Resizing that returns a Blob with a compressed image data. Can all types of
>> Blobs be 'read' using FileReader? If not, then it would be logical to only
>> accept File parameter. If any type of Blob can be read (as I think the
>> spirit of the spec assumes) then would it be less confusing to cange the
>> name to BlobReader?
>>      
> I'd support that.  I think we always want to allow reading of any type
> of Blob--it's the interchange container--so calling it BlobReader
> makes sense.  Arun, how do you feel about that?
>    

The FileReader object accepts File objects for DataURL-reads, and Blob 
objects for binary string, text, and binary reads.  I agree that having 
a name like FileReader is generally a bit confusing, given that we do 
allow Blobs to be read, including Blobs which aren't directly coined 
from files.  Blob itself isn't a great name, though it's a stand-in for 
Binary Large Object.

Aside from the slight bikeshed-ish nature of this discussion, there are 
implementations in circulation that already use the name FileReader 
(e.g. Firefox 3.6.3).  This doesn't mean I'm against changing it, but I 
do wish the name change suggestion came earlier.  Also, I'm keen that 
the main object name addresses the initial use case -- reading file 
objects.  Perhaps in the future Blobs that are not files will be the 
norm; maybe then, Blob APIs will evolve, including implementations with 
ArrayBuffer and potential streaming use cases getting addressed better.

Perhaps it is late to have a name change, and we've added to 
less-than-adequate naming on the Web (example: XMLHttpRequest).

> Would FileWriter ever be used to write anything other than a File?  I
> think not, so it should probably stay as it is, despite the lack of
> symmetry.
>
>    
>> 2. The FileReader.result is a string.
>>      

Actually, in my next draft, I will have FileReader.result be of type 
'any' (WebILD's 'any') since it could also be an ArrayBuffer (using the 
readAsBinary method, which will function like the other asynchrous read 
methods, but read into ArrayBuffers across the ProgressEvent spectrum.

-- A*

Received on Tuesday, 18 May 2010 21:56:49 UTC