W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XMLHttpRequest.responseBlob

From: Darin Fisher <darin@chromium.org>
Date: Mon, 26 Apr 2010 23:03:34 -0700
Message-ID: <k2ibd8f24d21004262303q6eaf1426o659093cc8539936a@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
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?

-Darin
Received on Tuesday, 27 April 2010 06:04:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT