- From: Arve Bersvendsen <arveb@opera.com>
- Date: Wed, 23 Sep 2009 12:59:29 +0200
- To: public-device-apis <public-device-apis@w3.org>
On ISSUE-6, here are some initial thoughts: First, we seem to be lacking a consistent definition of "Application". The BONDI Interfaces Requirements document, [1], does not actually define what an application is, but seems to be lumping it into one of two categories: A launchable application that you can pass arguments to, or as handlers for specific Content-types or protocols. In these items, BONDI identifies some specific application types: 1. Telephony Requirements: MUST be able to launch telephony application, and MUST be able to specify call type. The call type is, arguably, a protocol, and as such, this requirement could already be met by the openURL interface on the Widget interface 2. Messaging Also handled as a protocol handler (smsto) and the openURL interface. More advanced functionality would better be handled by a specific messaging interface, such as Nokia's messaging API strawman. 3. Browser: See 1/2 and widget.openURL 4. Camera: Some of the requirements on camera indicates that it actually has needs that may not be adequately met by an application launcher API: * A Web Application MUST be able to launch the native camera application. This is fair enough. * It SHOULD be possible to specify the camera to be used (e.g. rear or front). * It SHOULD be possible to specify the media type (e.g. still image, video etc.). * It SHOULD be possible to specify the resolution of the media. These are however not so clear, given that you would need to introspect the camera capabilities. Further, the requirements are mute on how to handle the image from the camera: * Is launching the camera synchronous or asynchronous? * How do you detect which image(s) are taken by the camera application? Camera is a fairly specific application type that might be best handled by a more specific API, and if a requirement is to remain, only the "launch the native camera application" would remain. In that case, an HTML5-based strawman would be to simply use <input type="image"> 5. Media player * A Web Application MUST be able to launch the native media player. * It MUST be possible to specify the content to be rendered or played. Material for a content-type handler interface instead? Now, on to the generic requirements listed in the BONDI document referenced (Section 5.1, page 26): 1. A Web Application MUST be able to launch an application. Fair enough, but I would rather move such a requirement to "should". There is no guarantee that the application exists, or that system policy permits the application launching. 2. It MUST be possible to identify a specific application through an Application ID. This is unworkable in environments that aren't strictly controlled from the bottom up. Looking at _just_ /usr/bin on a *nix system reveals some 1500+ applications, : $ ls -l | wc -l 1568 Further, the BONDI requirement labelled "IFC-0090" (and all dependent requirements), which says: A Web Application MUST be able to discover the installed (i.e. registered) applications and their Application IDs available in the Terminal. ... is unworkable in the same enviroments, as the applications in said environments would need to be manually crawled, raising both performance, privacy and security issues. I'll make a proposal for requirements which can remain, and may result in an interoperable specification in heterogenous environments. ___ [1] <URL:http://bondi.omtp.org/1.0/apis/BONDI_Interface_Requirements_v1.0.pdf> -- Arve Bersvendsen Opera Software ASA, http://www.opera.chom/
Received on Wednesday, 23 September 2009 11:00:11 UTC