Hi All, I'm interested in adding support for XHR.responseBlob to webkit and chrome. It sounds like we have a general consensus to add two new members to the XmlHttpRequest interface:
attribute boolean asBlob; // at least for the sake of discussion, calling it that for now readonly attribute Blob responseBlob; Another name option could be 'downloadAsBlob'. Personally, I like 'asBlob' for its brevity and its naming similarity to 'withCredentials'. Looks like the semantics of when its valid to call setRequestHeaders also applies setting the asBlob attribute; after open() but before send() has been called. An attempt to set the value at some inappropriate time should throw an INVALID_STATE exception. Also the asBlob attribute value should probably be reset to 'false' upon return from open(), again similar to how the request headers are cleared out upon return from open(). Anne, have you been following this discussion, wdyt? Michael On Tue, Jun 29, 2010 at 4:31 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Tue, Jun 29, 2010 at 4:24 PM, Eric Uhrhane <er...@google.com> wrote: > > On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking <jo...@sicking.cc> > wrote: > >> On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane <er...@google.com> wrote: > >>> The discussion at [1] got tangled up with the debate of .URL vs. .url, > >>> so I'm starting a new thread to pick back up the original topic: how > >>> do we save binary data from XMLHttpRequest? Here's my proposal [built > >>> mainly from the good ideas other folks posted in the original thread]. > >>> > >>> Use case 1: the developer wants to download a Blob of data, use it for > >>> a while [e.g. slicing out sub-Blobs and displaying them as images], > >>> then have it go away automatically. > >>> Use case 2: the developer wants to download a Blob of data, saving it > >>> in a location of the user's choice outside the sandbox. > >>> Use case 3: the developer wants to download a Blob of data, save it in > >>> the sandboxed FileSystem, and access it again later. > >>> > >>> XHR will have a responseBlob property. > >>> In order to signal the XHR that it should spool to disk and supply > >>> responseBlob, a flag must be set before send() is called. Call this > >>> wantBlob for now, although a better name would be appreciated. > >>> If wantBlob is set, responseBlob will be valid when the XHR completes, > >>> and responseText and responseXML will be null. > >>> If wantBlob is not set, responseBlob will be null, and the XHR will > >>> function as it does now. > >>> > >>> When wantBlob is set, on all progress events before the XHR is > >>> complete, responseBlob will be null. As of completion, it will return > >>> a Blob containing the full contents of the download. [We could later > >>> add incremental Blobs in progress events, but let's keep this simple > >>> to start with.] > >>> > >>> This satisfies use case 1 as-is. > >>> With the BlobWriter spec [2], as currently written [assuming we agree > >>> on how to get our hands on a BlobWriter], it takes care of use case 2. > >>> With the FileSystem spec [3], as currently written, it takes care of > use case 3. > >>> > >>> I think this takes care of the major use cases, doesn't force anyone > >>> to implement FileSystem to solve the cases that don't really require > >>> it, removes any need for synchronous IO, and is pretty simple for > >>> developers to understand and use. What do you think? > >> > >> Sounds great to me! Also note that this will allow > >> > >> Use case 3': the developer wants to download a Blob of data, save it in > >> IndexedDB, and access it again later. > > > > I don't see Blob mentioned in the structured clone algorithm, although > > File is there. I doubt it would be much additional work to support all > Blobs. > > Indeed, it should be trivial. I think Blob didn't exist yet at the > time when the structured clone algorithm was last updated. > > / Jonas >
