Re: [FileAPI] Blob.URN?

On Fri, Apr 2, 2010 at 10:43 PM, Jonas Sicking <> 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.

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

> 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

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

I think the UI currently used for an "in progress" download would be
sufficient as a first pass.  Later we could come up with a slightly
better indicator for a "continuous" download.


Received on Saturday, 3 April 2010 06:16:09 UTC