Re: [FileAPI] Blob.URN?

On Fri, Apr 2, 2010 at 5:47 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.

I agree. My statement was that FileWriter is a better option than
using Content-Disposition headers. The latter also opens modal dialogs
without user intervention.

I'm all for improving things further though. My main point that I
don't think there is a good use case for specifying
Content-Disposition headers.

>> 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.

You still can't promise anything about file size. And with the current
dialogs the UA is free to improve on the current UI, for example by
doing content sniffing to make sure that the correct file type is
indeed being saved. Or run virus scanners on it etc.

>> 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.

I've so far thought of the main use case for multiple writing
something like a document editor, where the user chooses a file
location once, and then the web application can continuously save
every 5 minutes or so to that location. As well as any time the user
explicitly presses some 'save' button. It seems like this work flow
doesn't go well with the UI you are describing.

What use case did you have in mind for being able to continuously
write to a file?

Additionally, the problems I described above, of things like file size
or data not being known at the time the user chooses where to save the
file. And how do you describe to the user that he/she is granting more
than a one-shot write?

I'm not saying that I don't think we need continuos writing. I'm
saying that I think we additionally the existing save-as dialog but
for locally created data without going through Content-Disposition
hacks. And I'm also saying that I think creating good UI for continuos
writing will be hard.

/ Jonas

Received on Saturday, 3 April 2010 05:44:19 UTC