API drafts posted at W3C - web developer comments welcome!

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.











































APIDescription
CompassAllows 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.
PowerAllows 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.
CPUAllows 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.
DisplayAllows 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.
ConnectionAllows 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.
ThermalAllows web apps to learn about thermometers connected to the device.
The app can detect the current temperature and receive asynchronous updates
about temperature changes.
AudioAllows 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.
VideoAllows 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.
InputAllows 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.

For more complete information about compiler optimizations, see our Optimization Notice.

3 comments

Top
anonymous's picture

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.
____________________________
Edward

Andy Idsinga (Intel)'s picture

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.

jacace's picture

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/

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.