Re: XMLHttpRequest.responseBlob

On Tue, Apr 27, 2010 at 10:11 AM, Eric Uhrhane <ericu@google.com> wrote:

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

All true, but my suggestion was based on the notion that XHR would be
writing to a disk location in order to provide a Blob to that location.  So,
it might make sense to allow the application to specify the underlying file
location.  That seems to be what FileWriter can be used for.  The
application would presumably have access to the File that the FileWriter
modifies.

This could be useful in conjunction with <input type=saveas> to download a
file from the cloud to a location of the user's choice without requiring any
intermediate copy of the entire file.

-Darin