Giovanni,
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
https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=189767
.
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*
