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

Re: XMLHttpRequest.responseBlob

From: Eric Uhrhane <ericu@google.com>
Date: Tue, 27 Apr 2010 10:11:32 -0700
Message-ID: <w2r44b058fe1004271011n8b37c984v5f0aa688355ad21c@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher <darin@chromium.org> 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.
>>
>> 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?

A FileWriter is quite a bit more limited than a File/Blob.  You can't
slice it, for instance, and you can't write it to multiple files
without writing, reading back, and writing again.
Received on Tuesday, 27 April 2010 17:12:20 GMT

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