Re: Updates to File API

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?

2. The FileReader.result is a string. There could be useful cases where it
could be useful to read the data as ArrayBuffer. For example, if a page
tries to crack the JPG file to extract the EXIF metadata. Maybe returning a
Blob that can later be asked for ArrayBuffer would be as good.

Dmitry

On Fri, May 14, 2010 at 11:52 AM, Arun Ranganathan <arun@mozilla.com> wrote:

> On 5/13/10 9:32 PM, Darin Fisher wrote:
>
>> Glad to hear that you didn't intend sync access :-)
>>
>>
>
> I have thoughts on Blob and how it should behave (and about the inheritance
> relationship between Blob and File), which is why I left the unfortunate
> error in the editor's draft for now (commented out and caveated).  This is
> the subject of a separate email thread (but don't worry -- while my thoughts
> on Blob and ArrayBuffer may be in some flux, sync access to File objects is
> *always* going to be a no-no, I promise :-) ).
>
> Now aside from the Blob - ArrayBuffer relationship, which I introduced, the
> rest of the changes are in keeping with threads discussing the File API.
>
>
>  Can you define the contentType parameter to slice better?  Is that
>> intended
>> to correspond to the value of a HTTP Content-Type response header?  For
>> example, can the contentType value include a charset attribute?  It might
>> be
>> useful to indicate that a slice of a file should be treated as text/html
>> with a specific encoding.
>>
>>
>>
>
> I'm happy to define it better in terms of what it *should* be, but web
> developers are likely to use it in ways that we can't predict, which is why
> "forcing" Content-Types is useful, but weird.  Why exactly do you mean when
> you say that a "slice of a file should be treated as text/html with a
> specific encoding?"  Can you give me a use case that illustrates why this is
> a good way to define this?
>
>
>  I'm also a fan of providing a way to specify optional
>> "Content-Disposition"
>> parameters in the slice call.
>>
>
> So I'm really not a Content-Disposition fan, since all the use cases I've
> seen so far seem to be to "force download" behavior (or trigger Download
> Manager).  Is there something I'm missing -- e.g. is there something here
> that FileWriter or BlobBuilder do *not* address, that putting
> Content-Disposition on Blob URLs *does* address?  Sorry if I'm missing
> something obvious.
>
> -- A*
>
>