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

Re: XMLHttpRequest.responseBlob

From: Michael Nordman <michaeln@google.com>
Date: Mon, 26 Apr 2010 16:01:00 -0700
Message-ID: <z2qfa2eab051004261601z81d9bef2je5a952b58ec8dcce@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Darin Fisher <darin@chromium.org>, 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"
>

Not sure we need additional API for that. If the page doesn't access those
properties, its indicating that it doesn't need them.


>
> / Jonas
>
>
Received on Monday, 26 April 2010 23:01:28 GMT

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