Re: XMLHttpRequest.responseBlob

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.


>
> 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"


That's simple, the page doesn't touch .responseText or .responseXML on the
XMLHttpRequest object.  If they do, then the user agent will have to
re-encode the string (if needed) and make them available to script.

- James


>
> / Jonas
>
>