- From: Arun Ranganathan <arun@mozilla.com>
- Date: Tue, 29 Jun 2010 11:00:55 -0700
- To: Eric Uhrhane <ericu@google.com>
- CC: Web Applications Working Group WG <public-webapps@w3.org>, 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>
On 6/28/10 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? > I personally think this sounds workable. We could also have a responseArrayBuffer using the TypedArrays[4] proposal which wouldn't necessarily need asynchronous processing. -- A* > 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 > [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Received on Tuesday, 29 June 2010 18:01:37 UTC