System Applications Working Group

On this page:: Mission | Roadmap | Phase 2 | Participate | Communications
Nearby:: SysApps Wiki | Device APIs WG | WebApps WG | HTML WG
Administrative:: "My Actions" | "My Questionnaires" | Participants | Patent Policy Status | Public email list | Member email list

This group has now closed

The work items have been republished as Working Group Notes to indicate that they are no longer being worked on.

Mission

As defined in its charter, the mission of the System Applications Working Group is to define a runtime environment, security model, and associated APIs for building Web applications with comparable capabilities to native applications.

Work Items

Please note that work has stopped on all of the following specifications. Links are also provided to the GitHub repository and issue tracker for each specification, for historical purposes.

Runtime and Security Model for Web Applications (repository, issues): This document specifies a runtime and security model for Web Applications. It describes how an application is defined through an application manifest, and how it can be installed, updated and packaged. It also specifies how such an application can be put into the background, be put back in the foreground or woken up. Finally, the document describes the security model for such applications. This includes the permission model and the different security rules that would apply.
App Lifecycle (repository, issues): This specification extends ServiceWorkerGlobalScope [service-workers] with APIs for managing the lifecycle of an application and associated events. This work item only proceeded as far as an editor's draft.
The app: URL Scheme (repository, issues): This specification defines the app: URL scheme, which can be used by packaged applications to obtain resources that are inside a container. These resources can then be used with web platform features that accept URLs.
Task Scheduler API (repository, issues): This specification defines an API to schedule a task at a specified time. When the indicated time is reached, the application that scheduled the task will be notified via a functional event on a service worker. A task event will be delivered to a service worker, regardless of whether the application is active on user agent. Applications such as an alarm clock or an auto-updater may utilize this API to perform certain action at a specified time.
Contacts Manager (repository, issues): This specification defines a System Level API which offers a simple interface to manage user's contacts stored in the system's address book. A typical use case of the Contacts API is the implementation of an application to manage said address book.
Messaging API (repository, issues): This specification defines a System Level API which offers a simple interface to get access to mobile messaging services. A typical use case of the Messaging API is the implementation of a messaging client application that allows the user to send SMS and MMS messages as well as to access and manage the received SMS and MMS messages.
Web Telephony API (repository, issues): This specification defines an API to manage telephone calls. A typical use case of the Web Telephony API is the implementation of a 'Dialer' application supporting multiparty calls and multiple telephony services. A minimal structure for call history items is also defined.
TCP and UDP Socket API (repository, issues): This API provides interfaces to raw UDP sockets, TCP Client sockets and TCP Server sockets.

In addition, the System Applications Working Group started a work item on a JSON based Application Manifest format, and subsequently transferred control of this specification to the Web Applications Working Group on 21 May 2013.

Roadmap

The Working Group's charter divided the deliverables into two phases. The first was intended to focus on the execution and security models, and validating them through work on a small set of specific APIs, with a view to establishing the patterns and conventions that will be used for the remaining deliverables. The phase 1 deliverables are listed above.

The following are the Working Group's phase 2 deliverables.

Bluetooth API: A low-level API to interact with the Bluetooth hardware available on some devices. Examples: Tizen Bluetooth, B2G Web Bluetooth.
Browser API: An API that provides all the necessary items to build a Web browser that aren't otherwise available. Most notably, this provides all that is needed in order to safely instantiate a viewport onto the open Web, pretend that such a viewport is the top level window even if the browser's chrome is itself written using Web technology, etc. Example: B2G BrowserAPI.
Calendar API: An API that enables complete management of the device's calendars. Examples: B2G Calendar, Tizen Calendar.
Device Capabilities API (editor's draft, repository, issues): An API that exposes the capabilities available to the device. Example: Tizen System Info.
Idle API: An API to be notified when the user is idle. Example: B2G Idle.
Media Storage API: An API to manage the device's storage of specific content types (e.g. pictures). Examples: Tizen Media Content, B2G Device Storage.
Network Interface API: An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features. Examples: B2G Mobile Connection, B2G WiFi Information.
Secure Elements API: An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc. Example: Gemalto Secure Elements.
System Settings API (editor's draft, repository, issues): An API to manage the system's settings (e.g. time/clock settings, and personal preferences including privacy preferences). Example: B2G Settings.

Face to face meetings

The 1st F2F meeting was held 9-11 April 2013 in Madrid and hosted by Telefonica, see agenda and minutes

The 2nd face to face was held 27-29 August 2013 in Toronto and hosted by Mozilla, see logistics.

The 3rd face to face took place 11-15 November during TPAC 2013 in Shenzhen, China, see agenda.

The 4th face to face took place 8-9 April in San Jose, California, and hosted by eBay, see agenda.

The 5th face to face took place in Santa Clara during TPAC 2014 to progress existing work items and to discuss what we wanted to see in a new charter.

Communications

The main communication channel for this group is the publicly archived mailing list <[email protected]>.

Member-confidential messages and logistical discussions can be addressed to the member-only archived mailing list <[email protected]>

Patent Policy

This group operates under the W3C Patent Policy - see its Patent Policy status for more details.