- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 26 Apr 2010 16:11:30 -0700
- To: Michael Nordman <michaeln@google.com>
- Cc: Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Apr 26, 2010 at 4:01 PM, Michael Nordman <michaeln@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. >> >> 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. I'm not sure I understand how you envision the implementation working. You can't before hand know that the implementation won't ever access those properties (at least not without solving the halting problem). So you'll have to keep all the data in memory, just in case .reponseText is accessed. / Jonas
Received on Monday, 26 April 2010 23:12:23 UTC