- From: Brett Zamir <brettz9@yahoo.com>
- Date: Wed, 25 Jun 2014 07:50:08 +0800
- To: Robin Berjon <robin@w3.org>, frederick.hirsch@nokia.com, public-web-intents@w3.org
- CC: public-device-apis@w3.org, anssi.kostiainen@intel.com
- Message-ID: <53AA0EB0.2040908@yahoo.com>
Very nice to see momentum picking up on this. While you have made mention that wish services may be system applications, I would also like to request making at least explicit mention of the possibility that *wishes themselves may originate from system applications*, specifically the very compelling scenario where a user may be enabled by their OS file system desktop to supply a data file to the UA, which could grant read, and optional write, access to a wish service per the user's choices. If you can choose which desktop files can read and edit your files, why not be able to supply the files for viewing/editing directly to a web app without needing to go find the web app first (and then use its own file picker, etc.) or force developers to make each data file as a self-contained HTML application? _*Process flow*_ A user might begin the process via an "OpenWith" request from the OS file system, with their choice optionally indicating an explicit service. The request is then passed on with a command line flag to the user agent to initiate a user wish, with the file contents as payload (in binary or plain varieties as needed), so that the user will thereby either be brought to a wish service picker listing or directly to an explicit wish service of their choice. Once a wish service is determined and the wish granted, the grant() payload for an "edit" type wish would gain permission to overwrite the existing file on the user's desktop. (Ideally means could also be developed for supplying entire folders, e.g., on Windows, via its "SendTo" feature, as content.) Wish names could be determined by verbs from the OS (e.g., in Windows, the predefined ones are Open, Edit, Print, Play, Preview per http://msdn.microsoft.com/en-us/library/bb165967.aspx ), perhaps in interaction with the user's UA configuration or a local filetypes.json file placed in a directory (at least until such time as OS' provide more user-friendly, contextual, and Web-Wishes-aware UIs for managing the likes of Windows' OpenWithList/OpenWithProgids and default extension handler)* which: 1. associates file names there to (MIME) types (so that the user was not effectively limited to a single type associated with the file extension such as application/json) and, 2. optionally maps these MIME types to explicit wish services for relevant wish names. The UA might also enable opening the app into a specific profile, with the desktop handling such wishes in a manner that both: 1. integrates wish services into the OS desktop (e.g., a specific icon could be obtained in the task bar of Windows users) 2. allows the user to locally store their data The user would thereby be enabled to open say a local text/html file for web app editing and get a unique icon for such a individual word processing wish service, or a JSON file for a more specific type of application. This can be done today on existing OS'*, but I think it would benefit from standardization of the mechanism. Best wishes, Brett * I have been working to provide such a tool for Firefox (currently Windows only), but it is in its early stages and relies on registerProtocolHandler where explicit services are not indicated in the filetypes.json file: https://github.com/brettz9/webappfind . It uses postMessage() for granting targeted read/write privileges.
Received on Tuesday, 24 June 2014 23:50:51 UTC