- From: Darin Fisher <darin@chromium.org>
- Date: Thu, 13 May 2010 21:32:48 -0700
- To: arun@mozilla.com
- Cc: David Levin <levin@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
- Message-ID: <AANLkTim5BWB6mbkljfHqfLlp6_BP0ZoZsIuApf8-wcbN@mail.gmail.com>
Glad to hear that you didn't intend sync access :-) 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 also a fan of providing a way to specify optional "Content-Disposition" parameters in the slice call. It seems to me that Content-Disposition like Content-Type impacts the way that Blob.url might be interpreted. It is useful to enable Blob.url to be able to replicate what you can do with http:// URLs. I think this would make it easier for apps to use http://URLs while online and Blob.url while offline without changing the rest of their code. I'm specifically thinking of use cases like the "download" links for attachments in webmail apps. Regards, -Darin On Thu, May 13, 2010 at 8:21 AM, Arun Ranganathan <arun@mozilla.com> wrote: > On 5/13/10 7:37 AM, David Levin wrote: > >> On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan<arun@mozilla.com> >> wrote: >> >> >> >>> Greetings WebApps WG, >>> >>> I have updated the editor's draft of the File API to reflect changes that >>> have been in discussion. >>> >>> http://dev.w3.org/2006/webapi/FileAPI >>> >>> Notably: >>> >>> 1. Blobs now allow further binary data operations by exposing an >>> ArrayBuffer property that represents the Blob. >>> >>> >> >> Does this imply *sync* access to the blob data? "new >> DataArray(blob.blobBuffer).getInt8(0);" >> >> > > A more sensible way is an additional asynchronous read method on > FileReader, which is what I should have done in the first place. Here, > partial data is going to be an interesting question. While partial strings > makes sense (for readAsBinaryString and readAsText), partial ArrayBuffers > gets us into a different area altogether. Any thoughts on partial reads > here? > > For now, I've caveated my (pretty major) mistake with an editor's note. > I'll update later today with a better way to expose this, but I'm thinking > something like readAsArrayBuffer on FileReader (with an open question on > partial reads). > > Also, does it imply the ability to modify the blob contents? (If so, what >> does this mean when there is a file backing it?) >> "new DataArray(blob.blobBuffer).setInt8(0, 0);" >> >> > > I'll let Eric speak to what BlobBuilder might want to do, but I'll strongly > disallow it in my draft :) > > -- A* > >> Thanks, dave >> >> >> > > >
Received on Friday, 14 May 2010 04:33:51 UTC