- From: Eric Uhrhane <ericu@google.com>
- Date: Thu, 1 Jul 2010 15:31:08 -0700
- To: Web Applications Working Group WG <public-webapps@w3.org>
The biggest unknown in the current BlobWriter spec [1] is how you
obtain one in the first place.
There are two current proposals, which I've summarized below. I've
heard only a few voices on this topic, and would love to get more
opinions. New proposals would be welcome as well.
If you favor one of the below, and don't think I've done it justice,
please do weigh in with further details.
Proposal A: a new input control.
You'd add markup such as <input type=saveas> or <button type=saveas>.
It could be styled however you please; it would pop up a standard
File-SaveAs dialog, so there's no security problem there. You'd
handle the event when the user selects a save location in order to
grab the BlobWriter.
Pluses:
It parallels <input type=file>.
It's user-initiated, so the default flow doesn't ever surprise the
user with a popup.
Proposal B: a new method on Window.
window.saveAs(function(blobWriter) { /* grab the writer and use it
*/}, function(error) {...});
Pluses:
It's a simple async API like many others we provide.
App developers are free to provide any UI or control flow they like.
In either case, we could add a parameter for the Blob, so that the
system knows what it's saving, and/or a suggested mime-type and base
name. Adding the Blob itself would let us eliminate the
writeFile()/save() call mentioned in [2], so that you'd only grab the
returned BlobWriter if you wanted to handle the progress events.
Eric
[1] http://dev.w3.org/2009/dap/file-system/file-writer.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1223.html
Received on Thursday, 1 July 2010 22:31:58 UTC