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

Santa Clara Face to Face at TPAC 2014

We held a face to face meeting in Santa Clara on Thursday/Friday October 30-31 to progress current work items, and to continue discussions on the new charter.

Dave Raggett organized a break-out session on trust and permissions during the TPAC plenary day on Wednesday October 29. This follows on from the Paris meeting on trust and permissions held on 3-4 September 2014, and discuss plans for launching a Community Group on trust and permissions for the Open Web Platform. See draft CG charter.

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.

The System Applications Working Group is aiming for full interoperability of website hosted applications across platforms, but regretably, developers may have to deal with variations between platforms when it comes to the details of how to create packaged applications for local installation. Web App scripts developed for the SysApps APIs should work across platforms without the need for changes.

Interested in helping to fulfill this mission? See below on how to participate.

Roadmap

The Working Group's deliverables are divided into two phases. In phase 1, the Working Group will focus on the execution and security models, and validating them through work on a small set of specific APIs. This will be used to establish the patterns and conventions that will be used for the remaining deliverables. The Working Group does not need to complete work on all the phase 1 deliverables before starting work on deliverables in phase 2. However, the Working Group should make substantial progress on some of the phase 1 deliverables before working on phase 2 deliverables, at which point it should be possible to do more work in parallel.

Below is the schedule for phase 1 as detailed in the initial Working Group charter. Note: App URI and App Manifest were split off from the Runtime and Security Model. App Manifest was subsequently transferred to the WebApps WG for use in both the regular apps and system apps security contexts. The extensions to App Manifest specific to the needs for system apps will now be covered in individual API specifications.

Specification	GitHub repository	Issues	Internal draft	Public Working draft	Stable draft (Last Call)	Implementors feedback (CR)	Notes
Active work
App Lifecycle	repository	issues	16 May 2014		Q3 2013	Q1 2014
App URI	repository	issues	11 June 2014	16 May 2013	29 May 2014	Q2 2014
Task Scheduler	repository	issues	13 October 2014	02 Dec 2014	Q4 2013	Q2 2014	Previously named Web Alarms
Contacts	repository	issues	04 Apr 2014	07 Mar 2013	Q4 2013	Q2 2014
Messaging	repository	issues	29 Nov 2013	16 May 2013	Q4 2013	Q2 2014
Telephony	repository	issues	14 Oct 2014	20 Jun 2013	Q4 2013	Q2 2014
TCP UDP Sockets	repository	issues	27 Oct 2014	02 Dec 2014	Q4 2013	Q2 2014	Previously named Raw Sockets
Inactive work
Runtime & Security Model	repository	issues	09 May 2013	21 Mar 2013	Q3 2013	Q1 2014	Discontinued in favor of App Lifecycle
App Manifest	repository	issues	16 May 2013	Transferred to WebApps WG on 21 May 2013, please see: repository, editor's draft

Phase 2

The following are the Working Group's phase 2 deliverables. The Working Group intends to make significant progress on some of the phase 1 deliverables before working on phase 2.

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: 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: An API to manage the system's settings (e.g. time/clock settings, and personal preferences including privacy preferences). Example: B2G Settings.

Specification	GitHub repository	Issues	Internal draft	Public Working draft	Stable draft (Last Call)	Implementors feedback (CR)
Active work
Device Capabilities	repository	issues	18 Dec 2013	Q4 2013	Q2 2014	Q4 2014
Secure Elements	repository	issues	10 Apr 2014	Q4 2013	Q2 2014	Q4 2014

Participate

Our work is subject to the general policies for W3C Groups. We welcome contributions from people outside of the Working Group, and note that we operate under the W3C Patent Policy. See licensing commitments for non-W3C Members.

If you are employed by a W3C Member and want to join this group, please ask your Advisory Committee Representative to nominate you to the group as explained in the relevant instructions.

If you are not employed by a W3C Member and have specific expertise to bring to this group, you are welcome to apply for Invited Expert status.

See the list of current participants.

We host our editor's drafts and issues on GitHub. Snapshots are released as W3C Technical Reports. Our discussions take place via email, and regular face to face meetings (about three a year). We use our wiki to collect use cases, Member contributions, and general information relating to the operation of the Working Group, e.g. our editorial process.

Note: the issues for each deliverable are linked from the corresponding GitHub repository (as linked from Roadmap). See also the list of general issues.

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.

We are planning a 5th face to face in Santa Clara during TPAC 2014 to progress existing work items and to discuss what we want to see in a new charter.

Communications

The main communication channel for this group is the publicly archived mailing list <public-sysapps@w3.org>.

Member-confidential messages and logistical discussions can be addressed to the member-only archived mailing list <member-sysapps@w3.org>

Patent Policy

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