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).
>
>
It doesn't seem too late to change the name.  FF could support both
FileReader and BlobReader.  One could just be an alias for the other.  It
seems like we have situations like this frequently when it comes to new web
platform APIs.  A name only becomes immutable once there is a lot of content
using it since user agents would be compelled to support the existing name
for compat with existing content ;-)

-Darin



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