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

Re: The most basic File API use case

From: Peter O. Ussuri <ussuri@threetags.com>
Date: Sat, 28 Nov 2009 12:45:58 -0500
Message-ID: <65dfc9010911280945m3543a751r3be1538efbe61405@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: public-webapps@w3.org
On Sat, Nov 28, 2009 at 11:38 AM, Nikunj R. Mehta

> 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.

Hi Nikunj, I checked DataCache API, but I could find no way to prepare
arbitrary binary responses, only DOMStrings as responses. What if I want to,
let's say, remove red eyes on a photo? I do need a way to prepare binary

Another issue: what if I want to download/save a file with a MIME type that
is "internal", like a picture, or a text file? I guess I'll need to set a
header for that. And what about popup-blockers now active most of the time?
Another issue: even if the download dialog is triggered, an empty window is
left open in some browsers (I am actually using this solution with Google
Gears API, so I see all these side-effects).

A direct saveAsDialog method is more robust and easier to use - using
DataCache API, even if all the issues mentioned above can be worked through,
is a work-around (clicking on a link should not be necessary).

> 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/
Received on Saturday, 28 November 2009 17:46:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC