Re: [FileAPI] Blob.URN?

On Thu, Apr 1, 2010 at 2:07 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher <darin@chromium.org> wrote:
>> On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane <ericu@google.com> wrote:
>>>
>>> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon <robin@berjon.com> wrote:
>>> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote:
>>> >>> The only way to get a FileWriter at the moment is from <input
>>> >>> type="saveas">.  What is desired is a way to simulate the load of a resource
>>> >>> with Content-Disposition: attachment that would trigger the browser's
>>> >>> download manager.
>>> >>
>>> >> I don't think that <input type=saveas> is a good solution for this, for
>>> >> one it falls back to a text input control, which is less than ideal. I think
>>> >> that the File Writer should trigger downloads on an API call since that
>>> >> doesn't introduce security issues that aren't already there. I'll make a
>>> >> proposal for that.
>>> >
>>> > Why not simply allow FileWriters be instantiated using:
>>> >
>>> > x = new FileWriter;
>>> >
>>> > And then make every call to .write open up the save as dialog.
>>>
>>> You wouldn't want to prompt on every write; developers might want to
>>> append a chunk at a time.
>>> You could prompt on creation, if you didn't mind that being a synchronous
>>> call.
>>>
>>> The reason I made an html element be the way of getting a FileWriter
>>> was to make the normal usage pattern not involve modal dialogs popping
>>> up in front of the user unprompted.  With an inpput control, they can
>>> choose when to interact with it, rather than having a speedbump shoved
>>> in front of them.
>>
>>
>> Please no more JS functions that block on modal dialogs! :-)
>> @sicking:  It seems odd to vary the behavior of .append based on how the
>> FileWriter was created.  Perhaps we should provide some other asynchronous
>> means of creating a FileWriter?
>
> I'm not suggesting any blocking JS functions. Calling
> FileWriter.write() is specified as an asynchronous function. This
> gives a great opportunity to display the save-as dialog and, if the
> user press 'cancel', fire an error event, otherwise start firing
> progress events.

Even without the JS API blocking, modal dialogs that come up without
user intervention are still annoying.  It's a much nicer experience
for the user to be able to call one up by clicking a SaveAs button or
the equivalent, don't you think?  It's also closer to the File Reader
API.

> Relying on asynchronous fetching of the FileWriter to deal with the
> save-as dialog seems to have two problems:
> 1. The file type isn't known at this time, so the user won't know what
> he's saving.

The user never truly knows what he's saving, even with a download, but
he does at least pick the filename in either case.
We could require a file type in the html element, if that would help.

> 2. This always seems to grant the web page the ability to write
> unlimited number of times and unlimited amount of data, to the given
> location. Today, for things like Content-Disposition, the user only
> grants the right to save a single, known, file once. This is enough to
> solve many use cases.

This is still just a single file, in a known location of the user's
choice.  It's just different that it's not closed right away, as with
a long-running download, but a bit more so.  How about this: we add a
close() call, after which no writes can be made.  From the time the
FileWriter's created until close() is called [or it's GCed, or the
document goes away], we consider the file open.  UAs are free e.g. to
display the download manager with an indication that the file's being
written, and the current byte count.  When you close the FileWriter,
it's like the download has completed.

Received on Saturday, 3 April 2010 00:48:10 UTC