Re: How to get a FileWriter/BlobWriter/BlobSaver

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