- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 18 May 2010 14:35:02 -0700
- To: Dmitry Titov <dimich@chromium.org>
- Cc: arun@mozilla.com, Darin Fisher <darin@chromium.org>, David Levin <levin@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
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:47 UTC