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

Re: The most basic File API use case

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Sat, 28 Nov 2009 08:38:57 -0800
Cc: public-webapps@w3.org
Message-Id: <493BB14F-5710-4C19-893D-E7B3BFC43D27@oracle.com>
To: "Peter O. Ussuri" <ussuri@threetags.com>

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.


[1] http://www.w3.org/TR/DataCache/
Received on Saturday, 28 November 2009 16:42:20 UTC

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