-
Notifications
You must be signed in to change notification settings - Fork 0
Standardization tasks
We have identified a list 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.
On a high-level, we would like to see the Runtime and Security Model for Web Applications spec to better consider and address non-mobile use cases for desktop, IVI, TV. We believe the current spec is too focused on mobile use cases.
See also: comparison with Tizen
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.
We need to clarify design principles, scope, use cases, and make sure they align with our high-level goals. Anssi started discussion on public-sysapps. Related to issue #43, issue #95, and issue #97.
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). Event pages used by Chrome Packaged Apps is one model to learn from.
Should investigate if window.open() will address all requirements for creating new windows. See also chrome.app.window which provides a more expressive API. Hongbo put up a rough draft of the Windowing API that can be used as input to the group.
Event registration for system messages is currently unspecified, see issue #73. See also event registration in the event page model of Chrome Packaged Apps.
Broadcast messages to same-origin globals API (see the comments 2 and 3, a strawman proposal) could address requirements for system messages (similar to SharedWorker-based messaging).
Clarify how the app lifecycle works, especially pausing/suspending. Perhaps add a lifecycle diagram.
- SysApps runtime
- Application.state:
running,paused,terminated - Event handlers:
Application.on{launch|pause|resume|terminate}ApplicationManager.on{install|uninstall}
- Application.state:
- Chrome Packaged Apps' runtime
-
States (
launched,suspended) not exposed via a sync API - Event handlers:
chrome.runtime.on{Startup|Installed|Suspend|SuspendCanceled|UpdateAvailable|BrowserUpdateAvailable}chrome.runtime.on{Connect|ConnectExternal|Message|MessageExternal}chrome.app.runtime.on{Launched|Restarted}
-
States (
The discussion around Manifest is happening in WebApps working group, no consensus yet.
The Event Page and Manifest integration needs to be specified. Pointers to relevant discussion below for follow-up:
"And if we want to enable event pages/workers to have synchronous access to its visible tabs, then a manifest could be used to describe the scope of that event page/worker such that the UA can make sure to put all relevant tabs in the same process." -Jonas of Moz
"Navigation Controller solves the grouping of a set of pages using an origin plus wildcard matching for a set of URLs, although as currently proposed a subset of those URLs might be something else altogether again, without much declarative control. For event pages/workers you'll want something similar. To identify what a URL's associated event page/worker is." -Anne of Moz proposes