Re: [FileAPI] Blob.URN?

On Fri, Apr 2, 2010 at 11:15 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Apr 2, 2010 at 10:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
>
> You can't always promise a filesize in normal downloads either, if you
> don't send the Content-Size header.  So any UI decisions that have to
> be made on how to display an unknown-size file have presumably already
> been made.

Good point. In theory UAs could in that case download the whole file
before asking the user. In practice they don't so maybe people don't
care. At least not yet.

>> 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.
>
> Which UI, the one that acts like a continuous download?

Yes. You'd be seeing a continuous download for as long as you were
editing the document.

>> What use case did you have in mind for being able to continuously
>> write to a file?
>
> One that we thought of today was the case of playing a game over the
> web (perhaps using WebSockets?) and wanting to save a replay.  You
> don't want to have to build up a Blob until the very end, and then
> deal with all the possible failure conditions.  If the user's power
> goes out halfway, frex, it would be nice to at least have a partial
> file downloaded.
>
> Another is to save to disk a streaming video resource that you are
> viewing part of at the moment.  Same concerns apply - you'd like a
> usable file with as much data as possible in it despite any failure
> modes.

Streaming data to a file is indeed an interesting use case. I agree
that in that case a continuous download indicator would be ok.

The main problem I have with the currently suggested UI is that it
still doesn't explain to the user what he is granting at the time when
the user is asked to grant access. It's only after the user has only
granted access that it's explained what is happening. That seems like
a problem.

I would have much rather focused on starting simple and create an API
for the already existing "save as" dialog. That is a problem that has
already been solved for a long time, and so we wouldn't have to argue
about if a good UI can be created. It is also the feature set that we
had previously discussed on this list as being a good starting point.

/ Jonas

Received on Tuesday, 6 April 2010 20:43:49 UTC