- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 9 Jul 2010 17:44:35 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>
On Fri, Jul 9, 2010 at 4:42 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > 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. More like this? var writer = new SimpleFileWriter(blob, optionalName); writer.onerror = onError; writer.onwriteend = onWriteEnd; > Other thoughts: > - I still think the names should be prefixed with File, not Blob. That's fine for the writers; I like your logic that a FooWriter writes to a Foo, not from it. I think the converse is true for a reader, so BlobReader makes the most sense. > - 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? Should we spec that, or leave it loose? One option I was just discussing over here was that if it's in response to a user gesture, it pops up a SaveAs dialog; if it's not, it goes to an infobar. I don't want to spec this so closely that UAs can't experiment a bit. > - 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 Saturday, 10 July 2010 00:45:22 UTC