W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: File API Feedback

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Fri, 19 Jun 2009 13:01:34 +0200
Message-ID: <65307430906190401w40ac7480i33d53af67e3c3b1c@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>
For what concerns the "file as URI" feature:
What about reusing the "cid" scheme?

- It would avoid collisions, as anything can be used as Content-ID,
including a progressive number or the name of the input element
- It would not be problematic to implement, as "cid" URIs are already
supported by browsers
- It would respect theoretical purity, as the identifier actually
represents the Content-ID of the file subpart in the
"multipart/form-data" submission
- It would bind to the <input type=file>: changing the file selected
automatically changes the reflected content, and the application
cannot send or read files the user had selected and then changed (not
through this API, at least)

For what concerns the "file dialog" feature:
<input type=file> (or <xf:upload>) cannot completely replace the
FileDialog interface because they cannot:

- open FileDialog without user intervention. This can be annoying, but
can also be useful, if the FileDialog is the result of a remote server
response
- do something in between user interaction and opening of the file
dialog box (for example checking a database or asking more data from
the user with a prompt() dialog)

Lastly: a new approach to the "file dialog" feature is
"about:fileselection", ie an URI that represents the file dialog box.
The difference between this and FileDialog is that it can be used from
an <iframe>, to avoid proliferation of modal dialog boxes. Also, the
settings for showModalDialog() would apply to automatic opened file
dialogs, without requiring new code and new heuristics to block them.

Giovanni
Received on Friday, 19 June 2009 11:02:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT