W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [FileAPI] Blob.URN?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 2 Apr 2010 23:15:18 -0700
Message-ID: <g2tdd0fbad1004022315t9388eb48oa312e9a7fb2960c1@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Eric Uhrhane <ericu@google.com>, Darin Fisher <darin@chromium.org>, Robin Berjon <robin@berjon.com>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
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.

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

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

~TJ
Received on Saturday, 3 April 2010 06:16:09 GMT

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