W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2009

ISSUE-6: Application launcher

From: Arve Bersvendsen <arveb@opera.com>
Date: Wed, 23 Sep 2009 12:59:29 +0200
To: public-device-apis <public-device-apis@w3.org>
Message-ID: <op.u0ph5f00byn2jm@galactica>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC