- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 2 Apr 2010 23:15:18 -0700
- 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 UTC