W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XHR.responseBlob and BlobWriter [nee FileWriter]

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 29 Jun 2010 16:31:46 -0700
Message-ID: <AANLkTilEpjIx6GT01gx8-HGIl_7oJIkeg8la4zE8qYVA@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
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 4:24 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.

Indeed, it should be trivial. I think Blob didn't exist yet at the
time when the structured clone algorithm was last updated.

/ Jonas
Received on Tuesday, 29 June 2010 23:32:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT