W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: The most basic File API use case

From: Arun Ranganathan <arun@mozilla.com>
Date: Fri, 20 Nov 2009 16:32:39 -0800
Message-ID: <4B073527.507@mozilla.com>
To: "Peter O. Ussuri" <ussuri@threetags.com>
CC: public-webapps@w3.org
Peter O. Ussuri wrote:
> Hello!
> This is in reply to Eric Uhrhane's message, and other discussions [1]
> Various File API use cases discussed in this mailing list are designed to
> illustrate some kind of expansion of existing browser capabilities, with
> ensuing discussion of potential new security risks. However, there is one
> quite general use case that is very unlikely to introduce any additional
> security issues and that is easy for everybody to understand (and for
> browser vendors to implement).
> I would like to suggest a "Group 0" File API use case, in Eric's
> terminology.
> Basically, there should be a way to do in JavaScript everything most
> browsers currently in use (including IE6) do without server round-trip. In
> the most general terms, it is currently possible, and relatively secure, to
> let the user select a file for upload, upload it to the server, do arbitrary
> processing, and then download/save the (new/modified) file back onto the
> user's local file system.
> The current File API draft lets a web app to read the file, but there seems
> to be no easy way for a web app to construct an arbitrary binary file and
> trigger a SaveAs/download dialog, with the file name suggested by the app.

I agree with this use case being a logical next step.
> The main idea here is to allow a "rich" client to be at least as functional
> as a "poor" html+server app is (w/o any dynamic client-side scripting). By
> recognizing this most basic use case, it will probably be easier to agree on
> the first iteration of FileWriter api, as most security issues have already
> been fleshed out.
> Required api is quite simple to define and implement: a file builder
> (similar to BlobBuilder in Google Gears), and a "SaveAs" method that takes
> "pre-built" files (blobs). And later this basic API can be extended to
> introduce an event model and cover more advanced use cases.

+1 -- I think this identifies immediate next steps well, along with Eric 
Uhrhane's groupings.

As far as Group 0 goes, I agree and think we'll need:

1. A script initiated SaveAs mechanism.

2. Something like BlobBuilder (as you point out).

Next steps can evolve from these.

-- A*
Received on Saturday, 21 November 2009 00:33:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:02 UTC