Re: File API Feedback

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*

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