Skip to content

Standardization tasks

Anssi Kostiainen edited this page Sep 6, 2013 · 9 revisions

We have identified a set of standardization tasks that we need to get started with. We hope to get to a point where we have clear visibility and accountability for contributions from each team/site, assuming responsibility for sub-tasks of Crosswalk.

The page shares its basic structure and boilerplate with Development tasks for consistency.

Table of Contents

Runtime and Security Model for Web Applications

On a high-level, we would like to see the Runtime and Security Model for Web Applications (partially obsoleted as of 2013-09) spec to better consider and address non-mobile use cases e.g. desktop web browsers, and web runtimes in desktop context. We believe the current spec is too focused on mobile use cases. For example, parts of the spec (e.g. Application Lifecycle and Events) address issues relevant to web browsers and regular web apps too. We should split these parts out i.e. modularize the currently monolithic specification.

Relevant W3C working groups:

  • SysApps working group (public-sysapps) - Runtime and Security Model, Package Format (incl. Web Manifest extensions for Packaged Apps), SysApps APIs
  • WebApps working group (public-webapps) - Web Manifest
See also: comparison with Tizen (NB! the comparison is against the now largely obsoleted version of the SysApps Runtime Model spec)

Tasks (high priority)

Application Lifecycle and Events (Kenneth and Anssi)

Status: draft spec available

Application Lifecycle and Events draft is being worked on in the SysApps working group. See the draft for use cases, requirements and the draft spec.

Manifest

Status: exploring

The Web Manifest spec is scope for the WebApps working group, targeted at regular web apps. Extensions specific to Packaged Apps to be specified in the SysApps working group.

The "event page" and Web Manifest integration to be specified. Pointers to relevant discussion on public-webapps for follow-up: event pages/workers synchronous access to its visible tabs, the grouping of a set of pages using an origin plus wildcard matching

Package Format

Status: exploring

Tasks (low priority)

Multiple window support (Hongbo)

Status: exploring

Closely related to the Application Lifecycle and Events proposal. see the strawman proposal for Application Windowing.

Managing multiple windows is an important use case in non-mobile contexts. Hongbo Min started discussion, related to issue #98 and issue #100. We should revisit these issues and try get the spec better address non-mobile use cases.

Related to multiple window support, we need to investigate how to prevent race conditions (see issue #100).

Should investigate if window.open() will address all requirements for creating new windows. See also chrome.app.window which provides a more expressive API. See also Mozilla's extensions to window.open() that require special privileges.

Privileged Applications extensions (Anssi)

APIs that are not web-facing should be split into their own specification. Anssi proposed on the public-sysapps to split ApplicationManagement interface and other parts of the Runtime spec relevant to privileged applications only into their own spec. Related to issue #4 and issue #92.

Design principles (Anssi)

We need to clarify design principles, scope, use cases, and make sure they align with the high-level goals. Anssi started discussion on public-sysapps, see also the Application Lifecycle and Events proposal. Related to issue #43, issue #95, and issue #97.

Clone this wiki locally