Re: Updates to File API

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 Friday, 14 May 2010 18:53:05 UTC