- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 09 Jul 2010 16:42:13 -0700
- To: Eric Uhrhane <ericu@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>
On Jul 8, 2010, at 3:47 PM, Eric Uhrhane wrote: > On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane <ericu@google.com> wrote: >>> 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. >> >> I'm not a fan of the <input type=saveas> solution. In part because no >> actual input is occurring. If we really want something like that then >> I think reviving the old <bb> element is the way to go. > > The user is inputting a location at which to save the file. > >> However what I really think we should do is to provide some API which >> given a blob and an optional filename, asynchronously returns an >> object at which progress events are fired and which has an abort() >> function. I don't care much if this function lives on a new object, >> a'la SimpleFileWriter, or if it's added to something like the >> Navigator object. > > OK, I'm not hearing any support whatsoever for option A, so let's go > with something like SimpleFileWriter/BlobSaver. > > How about this? > > var blobSaver = window.saveAs(blob); > blobSaver.onerror = onError; > blobSaver.onwriteend = onWriteEnd; It would be great if we could avoid adding methods to Window with simple and common names like saveAs(), since they pollute the global namespace. saveAs sounds like a name that may well conflict with existing code. FileSaver or BlobSaver would be less likely to conflict, so perhaps the entry point can be a constructor, rather than a function. Other thoughts: - I still think the names should be prefixed with File, not Blob. - What would the behavior be? Would this pop up a dialog where the user picks a file? If so, should it be subject to a user gesture limitation? - Part of the objection to <input type=saveas> is because there is no input occuring. But HTML5 also has an <output> element. Perhaps <output type=file> is an option worth considering? Regards, Maciej
Received on Friday, 9 July 2010 23:42:49 UTC