This draft is no longer active; the group has decided not to revise it further. The requirements defined in this draft are outdated and do not form the basis of contributions to the group. The Device APIs WG is currently not pursuing the approach outlined in this draft, so it should be considered expired. Please treat this document with caution and do not reference it or use it as the basis for any implementation/contribution.

This document summarizes the requirements and design decisions for the API work undertaken by the Device APIs and Policy Working Group.

Introduction

In the process of defining the APIs on which the Device APIs and Policy Working Group is chartered to produce, the group has identified a number of requirements that these APIs need to follow, as well as made a number of design decisions.

This document summarizes these requirements and design decisions, both to help evaluating the APIs the Working Group produces, and to serve as input to others who would want to write similar APIs.

This document is not currently considered to be complete, but rather represents a snapshot of the DAP WG's thinking at the time of its publication.

Global Requirements

These requirements apply to all APIs produced by the DAP WG.

Should the APIs be made available on navigator, navigator.device, or straight off a window.device?

Application Configuration

Due to overlapping with Widgets: The widget Interface [[WIDGETS-APIS]] and with Web Storage [[WEBSTORAGE]], this deliverable has been dropped.

Application Launcher

The following requirements have been expressed.

The following requirements, while they could be considered to be functionally part of this API, are already addressed as part of the HTML5 [[HTML5]] Custom scheme and content handlers:

Calendar

This interface:

The above suggests support for only VEVENT. However Andrew McMillan makes the following point:

"Given that the differences between VEVENT & VTODO are trivial in comparison to the complexity of their common elements, and that VJOURNAL is entirely a subset of those, it seems to me there is very little to gain by removing VTODO and VJOURNAL from this specification. Removal might restrict clients from implementing some potentially useful functionality. The other supporting components of the specification like VALARM and VTIMEZONE seem to me so essential in any reasonable implementation of VEVENT that they don't even merit discussion."

May be considered in future versions

Camera

This interface:

Given support for capturing video, we need to take sound capture into account. Once that's supported, is there any reason not to support capturing sound on its own? If we go there, isn't this a Capture API, with the ability to list mikes?

If the user requests a given capture size which isn't available, do we refuse or do we fall back? If the latter (which is likely) what is the algorithm that is used to find the fallback? It could be (given a request for 1000x50):

We could very easily get bogged down in specifying camera capabilities and format feature variants — how do we decide which ones are reasonably in?

Communications Log

This interface:

Contacts

This interface:

Are there convincing use cases for supporting multiple address books in v1 (as opposed to just a default one, and maybe exposing more later)?

Do we need support for groups in v1?

File System

This interface:

Gallery

This interface:

Exposing metadata is tricky, often giving a choice between creating an endless ontology or building an open-ended system that guarantees no interoperability.

A lot of this functionality can be provided if the Gallery API is basically a way of accessing well-known parts of the file system, and if the File System API has a way of exposing sufficient metadata. This could make for a very simple API.

Messaging

This interface:

System Information & Events

This interface:

This mixes system information and sensors — should they be separate? Should we have some system information and a universal sensor API? How do we get interoperability out of that?

Tasks

This interface:

See the issues that are part of the Calendar API.

User Interface

This interface: