- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 27 Apr 2010 10:11:32 -0700
- To: Darin Fisher <darin@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher <darin@chromium.org> wrote: > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher <darin@chromium.org> wrote: >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher <darin@chromium.org> >> >> wrote: >> >> > There is some interest from application developers at Google in being >> >> > able >> >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> >> > The use case is to improve the efficiency of getting a Blob from a >> >> > binary >> >> > resource downloaded via XHR. >> >> > The alternative is to play games with character encodings so that >> >> > responseText can be used to fetch an image as a string, and then use >> >> > BlobBuilder to reconstruct the image file, again being careful with >> >> > the >> >> > implicit character conversions. All of this is very inefficient. >> >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> >> >> There has been talk about exposing a responseBody property which would >> >> contain the binary response. However ECMAScript is still lacking a >> >> binary type. >> >> >> >> Blob does fit the bill in that it represents binary data, however it's >> >> asynchronous nature is probably not ideal here, right? >> >> >> >> / Jonas >> > >> > >> > I think there are applications that do not require direct access to the >> > response data. >> > For example, >> > 1- Download a binary resource (e.g., an image) via XHR. >> > 2- Load the resource using Blob.URN (assuming URN moves from File to >> > Blob). >> > It may be the case that providing direct access to the response data may >> > be >> > more >> > expensive than just providing the application with a handle to the data. >> > Consider >> > the case of large files. >> >> Ah, so you want the ability to have the XHR implementation stream to >> disk and then use a Blob to read from there? If so, you need more >> modifications as currently the XHR implementation is required to keep >> the whole response in memory anyway in order to be able to implement >> the .responseText property. >> >> So we'll need to add some way for the page to indicate to the >> implementation "I don't care about the .responseText or .responseXML >> properties, just responseBlob" >> >> / Jonas > > > I thought about this more, and I came to the same conclusion as you. I > agree that we wouldn't want to support .responseText or .responseXML if we > were streaming directly to a file because the implied synchronous readback > from disk would suck. > I'm not sure how to add such a feature to XHR in a way that is not awkward. > Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest object > prior to calling send? A FileWriter is quite a bit more limited than a File/Blob. You can't slice it, for instance, and you can't write it to multiple files without writing, reading back, and writing again.
Received on Tuesday, 27 April 2010 17:12:20 UTC