W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: How to get a FileWriter/BlobWriter/BlobSaver

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 8 Jul 2010 15:47:52 -0700
Message-ID: <AANLkTiko1pUMFUAdmoKyTuiAWz40b2MiWOhfLSym9NCA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
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;
    ...

[where nothing actually happens until execution exits]
Received on Thursday, 8 July 2010 22:48:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT