- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Sat, 27 Jun 2009 14:44:08 +0200
- To: arun@mozilla.com
- Cc: WebApps WG <public-webapps@w3.org>
2009/6/25 Arun Ranganathan <arun@mozilla.com>: > 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. We don't need to put it into the FPWD (or even the version 1.0 of final API) >> - 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 :) The browser could assign a Content-Id to the file selected by the JS-invoked dialog box. >> - 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 > . Just an implementation bug, I guess. > 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 ;-) Something good in both theory and practice is better than something else only good in practice. >> - 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. Good. >> 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. The "about:" URI scheme exists for "browser stuff". It would just be a binding from a new value for about (fileselection) to "chrome://browser/user-interface/filedialog" or "res://comctl32.dll\filechooser" or "file:///usr/share/my-browser/ui/fileselection". It is not that difficult (else they would not use about: for easter eggs) > -- A* > Giovani
Received on Saturday, 27 June 2009 12:44:49 UTC