Re: How to get a FileWriter/BlobWriter/BlobSaver

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