The most basic File API use case

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.

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.


Peter O.

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html