- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Jul 2010 16:34:56 -0700
- To: Eric Uhrhane <ericu@google.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane <ericu@google.com> wrote: >> Following up on discussions mainly at [1] and use cases at [2], I'd >> like to propose splitting the BlobWriter [née FileWriter] class, with >> an eye to solving some UI problems and simplifying implementation. >> >> When saving a Blob to a location outside the FileSystem API sandbox, >> we want to prompt the user exactly once, and want to be able to >> indicate that a write is taking place, e.g. by throbbing the download >> indicator. We want the throbbing to go away as soon as the write is >> done, and we don't want the app to have continued privileges to write >> outside the sandbox. [That's been debated, but I think it's beyond >> the scope of what we're working on so far, so let's leave that case >> for later expansion.] >> >> When writing inside the sandbox, we probably don't need the throbber >> at all, and we definitely don't want to prompt the user on each write. >> Leaving aside the question of how one obtains a BlobWriter without >> using the sandbox and when exactly prompts happen [I'll open another >> thread for that], I think that: >> >> * We don't want to have the same API call cause prompts to pop up on >> some instances of BlobWriter and not others. >> * We don't want to have the same API call be reusable on some >> instances of BlobWriter and not others. >> >> I propose the following split: >> >> Define a parent class, SimpleBlobWriter, that's used for one-shot Blob >> export. This is what you use when you don't have the FileSystem API, >> when the user selects the save location. It contains a writeFile() >> method, which writes a Blob to a file in a single operation. It is an >> error to call writeFile if readyState is not INIT, so SimpleBlobWriter >> is single-use. Its other members are abort(), readyState, the ready >> state constants, error, length, and the progress event handlers, as >> defined in the current spec. >> >> Derive from SimpleBlobWriter the class BlobWriter, which adds >> position, truncate(), seek(), and write(), as defined in the current >> spec. This is what the FileSystem API's createWriter() call would >> return. >> >> This lets you have different APIs for different behaviors, and removes >> fields from SimpleBlobWriter that aren't actually useful without the >> FileSystem API. >> >> How does that sound? > > Sounds great! Actually, i realized that I have second thoughts on some details here. It would be great if the "save as" functionality provided by the SimpleBlobWriter worked such that at the time the "where do you want to save a file" dialog pops up, the UA already knows what Blob is going to be saved. This has several advantages over the UA first receiving a request to save something, and then receiving the data that is to be saved. For example: * If the Blob is a File, default the filename to File.name * Allows the UA to display the size of the file, thus allowing the user to save to different locations depending on the expected size of the file * Allows the UA to determine the type of the Blob and adjust the filename based on that. Firefox does this for content-disposition save-as dialogs. As a separate question, at what URL are the latest drafts available? Is http://dev.w3.org/2009/dap/file-system/file-writer.html still authoritative? / Jonas
Received on Thursday, 1 July 2010 23:35:58 UTC