- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 28 Jun 2010 18:58:24 -0700
- To: Web Applications Working Group WG <public-webapps@w3.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Darin Fisher <darin@chromium.org>, James Robinson <jamesr@google.com>, Michael Nordman <michaeln@google.com>, Thomas Broyer <t.broyer@gmail.com>
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?
Eric
[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html
[2] http://dev.w3.org/2009/dap/file-system/file-writer.html
[3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
Received on Tuesday, 29 June 2010 01:59:09 UTC