W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2014

Wish opening initiated by the file system; Was Re: [webintents] Should DAP revisit WebIntents?

From: Brett Zamir <brettz9@yahoo.com>
Date: Wed, 25 Jun 2014 07:50:08 +0800
Message-ID: <53AA0EB0.2040908@yahoo.com>
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
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 

This can be done today on existing OS'*, but I think it would benefit 
from standardization of the mechanism.

Best wishes,

* 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC