Re: XHR.responseBlob and BlobWriter [nee FileWriter]

On Tue, Jun 29, 2010 at 11:28 AM, Jonas Sicking <> wrote:
> On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane <> 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.


Received on Tuesday, 29 June 2010 23:25:21 UTC