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*
