Re: The most basic File API use case

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/