Re: Updates to File API

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?

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

You're going to give a Blob to a FileReader, and get the same Blob back?

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

Received on Tuesday, 18 May 2010 21:35:48 UTC