- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 26 Apr 2010 16:08:04 -0700
- To: James Robinson <jamesr@google.com>
- Cc: Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Apr 26, 2010 at 4:02 PM, James Robinson <jamesr@google.com> 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. > > The user agent still has to keep the whole response around. The advantage > of being able to refer to the response body as an opaque handle is that the > user agent does not have to re-encode the entire response body just so > javascript can pass the response back to some other system that wants the > original binary data. Darins requested use case was large enough data sets that he didn't want to keep them in memory, as I understood it. So the expensive part isn't encoding to the desired charset, but simply keeping megabytes of data in memory. / Jonas
Received on Monday, 26 April 2010 23:08:56 UTC