- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 29 Jun 2010 16:24:35 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, Darin Fisher <darin@chromium.org>, James Robinson <jamesr@google.com>, Michael Nordman <michaeln@google.com>, Thomas Broyer <t.broyer@gmail.com>
On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane <ericu@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. Eric
Received on Tuesday, 29 June 2010 23:25:21 UTC