API drafts posted at W3C - web developer comments welcome!

By Andy Idsinga (Intel) (7 posts) on October 22, 2009 at 11:16 am

The other day ago our team, including Clayne Robison who also has a blog here on ISN, posted some API drafts to the W3C's Device API and Policy Working Group.

In a previous post I kicked off a conversation with web developers about exposing device capabilities as javascript APIs and widgets in the browser.

Here's your chance to comment and help inform our web developer enabling activities. Tell us about how having better access to the device's hardware capabilities would make your web app implementation easier. Maybe you have a use case you would like to share?

Here is a list of APIs for device capabilities we proposed.

API Description
Compass Allows web apps to make use of a device's compass. The app can detect the
current orientation and receive asynchronous updates when the
orientation changes.
Power Allows web apps to learn about the device's power state.
The app can detect the current power level, time remaining and receive
asynchronous updates about power level changes.
CPU Allows web apps to learn about the device's CPU - number of processors,
frequency, cpu usage levels.
The app can detect the current cpu usage and receive asynchronous
updates about cpu usage.
Display Allows web apps to learn about the device's display capabilities - dots per inch,
supported orientations, brightness etc.
The app can detect the current orientation and brightness and receive
asynchronous updates about display orientation and brightness changes.
Connection Allows web apps to learn about the device's network status and ability to
connect to services over the current network.
The app can detect check if an URL is reachable and check the latency
to and URL.
The app can receive asynchronous updates about network and service changes.
Thermal Allows web apps to learn about thermometers connected to the device.
The app can detect the current temperature and receive asynchronous updates
about temperature changes.
Audio Allows web apps to learn about the device's audio capabilities.
The app can determine which audio codecs are installed. The app can
also learn about speakers, microphones, lines in and lines out.
Video Allows web apps to learn about the device's video capabilities.
The app can determine which video codecs are installed and what formats
and profiles they support. The app can also determine if codecs support
hardware acceleration.
Input Allows web apps to learn about the device's user input capabilities.
The app can determine if the device has a touch screen, if it
has multi-touch support, if a physical keyboard is present or if a software
keyboard is visible. The app can receive asynchronous updates about
physical keyboard attach / detach. The app can receive asynchronous updates
about physical pointer attach / detach.

You can see the detailed API specs and example use cases at the WC3's site.
This is only the beginning. Stay tuned to the blog, or my tweets, for more API, widget and mashup proposals coming in the near future.

Categories: Software Engineering

Comments (2)

October 22, 2009 3:19 PM PDT

javierandrescaceres
Total Points:
4,680
Status Points:
4,180
Brown Belt
 Hello Andy,


Great innitiative.
Have you ever consider the wide possibilities while doing this kind of API? I had to do something similar in some project.
I mean, for example thermal devices can be attached to the motherboard and reading from them requires somethig like a driver and every different sensor does the reading and its own way (and there are lots of different kind of sensors).

Javier Andrés Cáceres Alvis
Blog Personal: http://speechflow.spaces.live.com/
Blog Intel: http://software.intel.com/en-us/blogs/author/javierandrescaceres/
October 22, 2009 5:29 PM PDT

Andy Idsinga (Intel)
 Hi Javier, thanks for reading and commenting!
Yeah the hurdle to web developers gaining access to sensors can be high. Our goal will be to leverage some of Intel's work and expertise in platforms and system software to make this lower.
My own background in embedded systems reminds me of the issues you raise.
A couple of projects back I was developing firmware and software for an RFID reader device attached via USB. There were several layers of software between the radio control firmware and the application software running up on the host device. Since our reader was a usb device, we had to comprehend host software running on both PCs and "embedded hosts". I see similar problems exposing device capabilities to the web browser. The web browser could be running on a traditional PC, and Atom based netbook or and Android smart phone. The layers of software need to support connecting a variety of browsers to a variety of device capabilities.

Trackbacks (5)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*