Architecture Proposal Validation

The new architecture proposal is the aggregation of multiple components. Even if those components have inter-dependencies, and/or may rely on platform improvements, it is possible to iterate on those independently.

For a more accurate description of the architecture proposal, please refer to https://wiki.mozilla.org/Gaia/Architecture_Proposal

Component Structure

This document tries to separate the proposal them into individual units of work, called component. Each component is described following the above structure:

Short description

This is a very concise description of the component. For a more precise definition or to understand how it is related to other parts please refer to https://wiki.mozilla.org/Gaia/Architecture_Proposal

Goal(s)

The goal is often to validate the component for the new architecture, and to identify early the possible pitfalls of the related component.

Pitfalls can be performance related, or developer story related. If any pitfall is found, the goal is to see if those are inherent to the architecture, or if there a technical solution that may solve it.

For example if a there an extra memory consumption for a component, is there anything that can be done from the platform side ?

Or if one component is making debugging harder, is there a devtool that can be created in order to make the situation better ?

If no goal(s) are indicated for a particular component, the goal refer to the previously described goal. If goal(s) are indicated for a particular component, it comes as an addition to the previously described goal.

Example of tasks

This is a non-exhaustive list of possible things to work on.

Example of dependencies

As mentioned components may have dependencies across other teams, or across the platform. This section is a non-exhaustive list of possible dependencies.'

Telemetry

Short description

Telemetry is a mechanism to observe how Gaia behave in the real world. It sends performance and usage information to Mozilla. It is an opt-in feature.

Goal(s)

While performance related telemetry reports are unoptimal with the current application blackbox model, custom reports may still be useful for todays applications. Having a great library here may help decision making.

Example of tasks

• Create an easy to use library for general metrics, such as:
  • startup time (using the Performance Timing API)
  • Memory usage (exposing about:memory informations to app content, maybe under a permission)
  • reflows count / time
  • Errors
  • Event Loop Lag
  • Async animation failures
  • Security warnings
  • Contract methods above the defined threshold
  • Navigation Map
  • Panel usage count / time spent

• Create an easy to use library for custom metrics. e.g, the number of contacts

• Create a mechanism to opt-in/out of telemetry. The scripts does not need to be included into the page if telemetry is disabled (maybe via ServiceWorker). A bonus would be to have an option to enable/disable telemetry on a per-app basis.

• Create a dashboard to make it easy to visualize the data. At first the primary target is developers, but since telemetry can be used for decision making it would be nice to also have specifics dashboard for marketting, QA, or even release engineering. For example, if telemetry reports that users are not using a particular panel, this is an valuable information to have when doing bug triage. If there is a bug in this panel, but nobody use it, we may not block on it.

Example of dependencies

• App developers to ensure the libraries are easy to use
• Firefox Telemetry team in order to see if their server code can be reused (this is a big beast)
• Platform folks. Some Gecko internals values needs to be exposed, such as the memory usage. But also, in workers the Performance API only expose the Now() method. While it would be useful to have the performance.timing API if Workers are used more consistenly across Gaia.

Updates

=== Still checking how it interacts with the security model ===

Service Worker

Short description

Service workers essentially act as proxy servers that sit between web applications, and the browser and network (when available.) They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server.

Example of tasks

• Create a set of lightweight libraries for making them easy to use. There should be at least 3 helpers:
  • Offline Cache
  • Custom Cache
  • Render Cache

• Identify Service Worker performance pitfalls.
  • For example if Service Worker is the first thing opened before opening the application, does it cause a performance regression ? (likely).
  • Does retrieving a file from the Service Worker for a particular request is efficient ? If not, it is because of the Service Worker backend ?
  • ...

• Help identifying the complex use cases for the Render Cache
  • For example the Gallery app is made of blobs. Blobs are tied to a document, which makes it hard to store in the render cache. How can it be solved.
  • Some applications include time based informations on some of their panels (the ultimate example beeing the Clock app). The panel logic should be the one responsible for serializing the panel, but how do we ensure the next rendering will be done in one layout step ?
  • Web Components are nice. But in the current shape they are not serializable. While it will force JS to run during the initial rendering, it may also force some relayouts. Is there any way to decouple Web Components rendering from their behaviors ?
  • ...

• Help shaping efficient cache eviction strategy for the Render Cache. Caching is powerful but evicting is painful.

• Help shaping the developer story around developing with Service Worker

Example of dependencies

• Devtools team to get some tools to debug Service Worker
• Platform team for bugs and performance related things
• UI Components team, to build fast and efficient reusable components

Data Sync

Short description

Synchronizing applications data offers a way to save the informations remotely, as well as opening the door to run a different UI to visualize those datas on a device with a different form factor.

Example of tasks

• Create a library to make it easy to synchronize datas remotely
  • Use Firefox Account under the hood
  • Crypto is done client side. Ensure it is done in a secure and efficient way.
  • For large set of datas, such as the Gallery app, it should be possible to enforce the synchronization on Wifi only.

• Investigate phone backups

• Prototype creating desktop UIs for some apps, in order to see if the proposed architecture helps with such cases.

Example of dependencies

• Content services team, to have an HTTP proxy for storing data remotely

Bridge

Short description

The bridge is a helper to manage communications between endpoints. It is also use to start those endpoints into various environment such as a Window or a Worker for the same code, as well as shutting down endpoints for performance optimizations. The bridge is very similar to client/server communication, where one endpoints act as a service for multiple clients.

Example of tasks

• Create a library to facilitate communication between web endpoints. For example endpoints can be a Window, a Worker, a Shared Worker, a Service Worker, a Cloud Worker, etc...
• Create a contract based communication mechanism for the mentioned library. The contract is a separate file which contains the list of methods and events available for a server. It contains typed informations for those, and may contains other debugging facilities such as a threshold for methods, in order to fire a telemetry reports if needed.
• Create a library to create/starts endpoints
• Create a library to stop/restart endpoints
• Create tool to let code designed for Workers to run into a window global. This is useful in some situations, and especially for debugging purpose since the devtools does not support debugging Workers yet.

• Identify performance pitfalls, such as the latency introduce with the event dispatching mechanism.

Example of dependencies

• Devtools teams to use / found bugs in their worker debugging code.
• Telemetry team to profile precisely the performance issues.

UI Components

Short description

Having reusable and efficient components across Gaia is a huge plus. Today Web Components are the technology used by Gaia. Ensuring applications use components, and enhancing them is a good use of time.

Goal(s)

Having good web component is a goal by itself. And for some parts, it can be landed from any architecture changes.

Example of tasks

• Design great components and ensure applications use them
• Allow Web Components to be serializable in the Render Cache
  • Investigate decoupling Web Components rendering, from their behavior
  • Investigate shutting down Web Components behavior when the application is in background

• Follow actively what is going on with Web Components in the standardization process. If needed, be ready to move away from Web Components, help shaping a new web standard, and implement and efficient mechanism into Gaia.

Example of dependencies

• Render Cache team for easy serialization / quick deserialization.
• Web Standard folks to observe the future of Web Components.

Lists

Short description

Lists are one of the core components of many apps. Having libraries for lists will be a huge plus.

Goal(s)

Having shared list component is a goal by itself. And for some parts it can be landed independently from any architecture changes.

Example of tasks

• Create multiple libraries based on Roc's proposal in order to optimize speed and memory consumption (see http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html)
• Start with a simple test case such as the dialer call log
• See if it applies for panels (except the main panel) of the music app. If needed create an other library.
• See if it apply for contacts. If needed create an other library.
• Ensure lists are serializable in the Render Cache
• Profile performance for overpaint, fps and memory consumption.
• Design a great API so it easy to bind datas for apps

Example of dependencies

• Layout team / Gfx team to ensure performance requirements are meet
• Render Cache team to see how it can be efficiently save into the cache and rerendered.

Navigations

Short description

Navigating between panels is one of the core component of all apps. Having system wide transition would be a huge plus. In the current proposal the transition is handle by a app-wide top level document, called the Content Wrapper. In the future, the idea is to get rid of this Content Wrapper in favor of a variant of the Navigation Transition API.

Example of tasks

• Work in the top level document of apps to manage navigation.
• Work with the platform to move forward to the Page Transition API
• Experiment multiple models of sub-frame organization in order to prioritize/deprioritize panels on the event loop
• Work with the bridge team since for the moment the Content Wrapper to start/shutdown capsules
• Emulate the pre-rendering API
• Profile performance of using one iframe per panel
• Stop/Reopen panels when the app is in background

Example of dependencies

• Layout/GFX team to move forward on the Page Transition API
• System team to see if there an intermediate steps for the Page Transition API, with a custom implementation in the System app