Re: XMLHttpRequest.responseBlob

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