Re: Updates to File API

On Tue, May 18, 2010 at 2:56 PM, Arun Ranganathan <arun@mozilla.com> wrote:

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


Ok, I can see how it can be late if FF already shipped it... Perhaps the
spec could at least avoid using 'fileBlob' as names of arguments, since the
naming currently may be interpreted as  if only file-backed blobs are
welcome :-)


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

Getting an ArrayBuffer on each ProgressEvent could be a cool idea indeed. I
guess when we have ArrayBuffers we'll be able to use them in BlobBuilder as
well.


>
> -- A*
>