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

Re: File API Feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Thu, 25 Jun 2009 07:16:48 -0700
Message-ID: <4A4386D0.2000301@mozilla.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
CC: WebApps WG <public-webapps@w3.org>

> For what concerns the "file as URI" feature:
> What about reusing the "cid" scheme?
This is an intriguing idea.  Other ideas I've experimented with include 
filedata:// but since cid has seen some usage (e.g. within email), it 
might be a good candidate.

Upon reflection, the research this task would take might delay a first 
draft of the FileAPI spec.
> - It would avoid collisions, as anything can be used as Content-ID,
> including a progressive number or the name of the input element
This makes a good case for cid:<inputElementName> but we ought to allow 
for files that aren't selected using input elements :)
> - It would not be problematic to implement, as "cid" URIs are already
> supported by browsers
This isn't quite true for Firefoc -- see for example 

If we go this route, this may enable other use case scenarios as well.
> - It would respect theoretical purity, as the identifier actually
> represents the Content-ID of the file subpart in the
> "multipart/form-data" submission
Theoretical purity is wonderful in theory ;-)
> - 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)
My first impression is that this seems like an attractive capability.
> 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. 
So this would be *another* URI scheme to refer to the opened file 
dialog?  This seems like overkill.

-- A*
Received on Thursday, 25 June 2009 14:17:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC