W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

[widgets] Device Specific APIs and Services

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Fri, 20 Jun 2008 18:37:35 +1000
Message-ID: <b21a10670806200137i439d405fwd5a82ab77c614d3d@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>

What follows is an *extremely rough* strawman proposal to address
"R30. Device Specific APIs and Services", of the widget requirements
document. This proposal is intended for discussion and is deliberately
thin on technical details.

Requirement 30 of the Widgets requirements document is as follows:
A conforming specification should specify a mechanism, either through
an API or through the configuration document, which allows
instantiated widgets to bind to third-party APIs that allow access to
device-specific resources and services. A conforming specification is
not required to specify any APIs to device specific resources or
services, but should provide some means of binding to those APIs if
they are available.

Current development practice or industry best-practices, ease of use.

To endow widgets with functionality beyond what is currently available
to HTML documents, allowing widgets to be used as means to bridge
special device capabilities and operating system services with data on
the Web. Examples of device-specific services and resources that could
be made available through script include cameras, SMS, geolocation and
 address book. There are other WGs working on this requirements such
as the Ubiquitous Web Applications Working Group (UWA-WG), and the
Open Mobile Alliance (OMA) Device Capabilities Working Group.

=The Proposal=
There are two aspects to the proposal: a declarative aspect and
programmatic aspect.

Declarative aspect:
The declarative side would involve declaring the intention to use an
API that may or may not be part of the standard set of APIs that
shipped with the widget engine. We declare the intention to use an API
in the configuration document for security purposes (the config.xml
file cannot be written to by the widget engine and the config file can
be digitally signed). APIs are identified as resources via URIs. For

	<access network="true">
		<requires id="gps"
				kind="api" />

The interfaces that bind this binary component to JavaScript would
need to be standardized and I have no idea what they would look like
at this point.

Programatic aspect
At runtime, in we would need something like the following interfaces:

interface APILoader{
  attribute APILoader APILoader(DOMString id); // the id declared
  void load();         //load the API
  void cancel();     //cancel loading

  //progress events...
  attribute EventListener onLoad;
  attribute EventListener onProgress;
  attribute EventListener onError;


interface api{
  Object bind();  //binds the api to runtime
  enum interfaces();  //returns a list of methods
  void unbind(); //removes the binding from memory

Example usage:
apiLoader = new APILoader("gps"); //must match an id in config.xml
apiLoader.onLoad = function(loadedAPI){
	gps = loadedAPI.bind();
        loc = gps.getLastLoc();

apiLoader.onError = function(loader){}

Marcos Caceres
Received on Friday, 20 June 2008 08:38:21 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:10 UTC