-
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. See also Mozilla's extensions to window.open() that require privileges.
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