MWI Team Blog

Dispatches from members of the W3C Mobile Web Initiative Team

Categories: Current state (31) | Developing Countries (14) | Events (16) | Looking forward (10) | News (35) | Technical (28) |

Exposing device capabilities to web applications — 6 February 2008

There is huge potential for mobile web applications that can access device capabilities from client-side scripts. There has been a lot of work on J2ME APIs for Java based applications, but we lack standards for exposing local device capabilities to applications running in web browsers. The time has surely come for W3C to bring interested parties together to work on fixing this as a matter of priority. Properties like location, with privacy and associated legal issues, will clearly be more complicated to deal with, as we will need to address the security and trust models involved. But other properties like battery level, signal strength, light and vibration control, should be much easier to progress. The Device Description WG is defining APIs for access to properties of classes of devices, and the OMA is defining a protocol and server-side API for access to dynamic properties (DPE) that will enable servers to dynamically adapt media streams to match device orientation and bandwidth. The UWA WG has recently moved DCCI to CR and published the first draft WD for an ontology for the delivery context, where the ontology is decoupled from the APIs that it models. DCCI is a client-side framework, but doesn't itself define any properties. With a little work, DCCI could be used for:
  • dynamic content adaptation on client
  • checking battery level, signal strength
  • controlling the display brightness
  • turning the phone's vibrator on and off
  • checking screen orientation and size
  • checking available free memory
The following will need work on trust models and could be part of a second wave, following a security workshop planned for late 2008.
  • implementing location-based services
  • interface to on-phone applications (PIM) including calendar and contacts
  • allowing web page scripts to initiate phone calls
It seems timely for the W3C Mobile Web Initiative to create a roadmap for building concensus on client-side access to device capabilities. This seems like something W3C should be taking a leadership position on given the opportunities for third party developers to stimulate mobile data traffic if we succeed in standardizing the APIs. Without such action there is a risk of fragmentation as multiple APIs appear and developers have to choose between them. What's the best way to bring together the relevant stake holders? For instance, browser vendors, device vendors, network operators and application developers?

Comments, Pingbacks:

Comment from: Peter Cranstone [Visitor] Email · http://www.5o9inc.com
Dave,

Everything you have outlined above can be done using nothing more than the current HTTP standard and a simple browser plug-in on the mobile device.

We can show you everything you are talking about in your post right now running over current HTTP standards talking to standard Apache or IIS web servers.

In addition our design allows for the consumers privacy to be maintained while keeping in place the current JavaScript sandbox - but yet allowing JavaScript to talk to the mobile device "IF" the consumer allows it.

Our solution can do all of the following:

# dynamic content adaptation on client

# checking battery level, signal strength

# controlling the display brightness

# turning the phone's vibrator on and off

# checking screen orientation and size

# checking available free memory

# implementing location-based services

# interface to on-phone applications (PIM)

including calendar and contacts

# allowing web page scripts to initiate phone calls

And more.

Cheers,

Peter
PermalinkPermalink 2008-02-07 @ 15:01
Comment from: Dave Raggett [Member]
Thanks for the info. A number of companies have explored the plugin approach, but so far there has been little work on common APIs. I think it is critical to bring together all of the stakeholders and perhaps a W3C Workshop sponsored by the Mobile Web Initiative might be a good way to assist with that.
PermalinkPermalink 2008-02-07 @ 16:45
Comment from: Mark Baker [Visitor] Email · http://www.markbaker.ca
The WHAT-WG/HTML-WG seems to have picked a handful of client-side services in HTML 5 that are in need of standardization, but beyond those I think there's a whole lot of innovation yet to happen, so premature standardization could really hurt. If any does happen though - because I admit that sometimes the need for a standard is greater than the cost of not standardizing - we should make sure that it's really truly needed.
PermalinkPermalink 2008-02-13 @ 18:29
Comment from: Aayush Bhatnagar [Visitor] Email
Regarding dynamic content adaptation on the client, can you please elaborate a little more? Does this mean, that the server rendering the service (service delivery platform for example)will not play a role in adapting the content according to the device capabilities? The client device will adapt the content by itself?
PermalinkPermalink 2008-04-17 @ 05:18
Comment from: Dave Raggett [Member]
One mechanism for client-side adaptation is CSS media types This allows you to specify media dependencies for style rules. Unfortunately, few mobile browsers implement the "handheld" media type which CSS 2.1 defines as being appropriate for handheld devices (typically small screen, limited bandwidth).

Another approach to client-side adaptation is to use a web-page script to show or hide parts of the markup, or to actively modify the DOM tree. Currently browsers provide very limited access to the delivery context, although you can get the width and height of the screen. However, it may also be possible to use XMLHttpRequest to access further information held on the Web server from which the page was downloaded. For instance, making use of the Device Description Repository API, defined by the W3C Device Descriptions Working Group.
PermalinkPermalink 2008-04-17 @ 07:50

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))

feedSyndicate this page |

Contacts: Dominique Hazael-Massieux