W3C home > Mailing lists > Public > public-ddwg@w3.org > February 2008

RE: Time to take a leadership position on client-side APIs

From: Dave Raggett <dsr@w3.org>
Date: Wed, 6 Feb 2008 17:01:03 +0000 (GMT)
To: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Cc: public-ddwg@w3.org
Message-ID: <alpine.DEB.1.00.0802061700180.13433@ivy>

I agree with Rotan that this shouldn't be restricted to mobile
devices, but it is a question of how to build critical mass to make
this happen in a timely way, and right now, mobile devices have the

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

On Wed, 6 Feb 2008, Rotan Hanrahan wrote:

> I agree with Dave's call to action, but I don't think that it is the responsibility of the Mobile Web Initiative to create the roadmap, even though the dominant use cases are in the mobile domain. The issue of client-side APIs accessible to applications within browsers is not confined to mobile. This is an issue that will touch all aspects of the Web, and while I would accept the MWI being the initial champion of an initiative on client-side APIs, it seems to me that the cause should be taken up at a higher level within the W3C. Confining this work to mobile would be a mistake.
> ---Rotan.
> ________________________________
> From: public-ddwg-request@w3.org on behalf of Dave Raggett
> Sent: Wed 06/02/2008 16:35
> To: public-ddwg@w3.org
> Subject: Time to take a leadership position on client-side APIs
> 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, 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:
>     * 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?
>  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Wednesday, 6 February 2008 17:01:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:51 UTC