On Nov 20, 2009, at 1:37 PM, 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.
There is currently a way to do so being defined in the DataCache API
[1]. The API provides for ways to generate a response payload, just
like any http server could upon receiving an HTTP request. So you
could insert a link with some URL on the page and register an offline
handler for that URL. When the user clicks on that URL, it will call a
DataCache interceptor, which is basically a JS function, to produce a
response. If the MIME type of the generated response requires browser
to use an external app, then it could easily spawn a file save/
application open dialog just like in the case of file downloads.
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.
Nikunj
http://o-micron.blogspot.com
[1] http://www.w3.org/TR/DataCache/
