Re: The most basic File API use case

On Sat, Nov 28, 2009 at 11:38 AM, Nikunj R. Mehta
<nikunj.mehta@oracle.com>wrote:

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

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