- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Fri, 20 Jun 2008 18:37:35 +1000
- To: "public-webapps@w3.org" <public-webapps@w3.org>
Hi, 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. Motivation: Current development practice or industry best-practices, ease of use. Rationale: 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 example: <widget> <access network="true"> <requires id="gps" src="http://gps.w3.org/api.jar" type="application/jar" kind="api" /> </access> </widget> 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; ...etc... } 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){ try{ gps = loadedAPI.bind(); loc = gps.getLastLoc(); catch(e){ } } apiLoader.onError = function(loader){} apiLoader.load(); -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
Received on Friday, 20 June 2008 08:38:21 UTC