Gaia/Toolkit/Service Worker

New Architecture

https://wiki.mozilla.org/Gaia/Architecture_Proposal

Service Workers

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 actions based on whether the network is available and updated assets reside on the server.

Tasks

Libraries

• Design and implement a set of lightweight libraries for making service workers easy to use. There should be at least 3 helpers to support the caches proposed for the new architecture:
  • Offline Cache
  • Custom Cache
  • Render Cache

There is currently some code (ServiceWorkerWare and Offliner) on the way that can be used as a starting point for these libraries.

Open questions

• How does the customization cache get populated? Is this a build-time step? Or is it tied to the update mechanism somehow?
• Caching rendered HTML makes less sense in a world where we make heavy use of web components. Do we really want to do both?
• I don't believe that the string concatenation required to build an innerHTML string actually takes very long, and caching rendered HTML seems brittle to me. Would it be better to design a solution that supports caching of localized strings and caching of the data needed to render the first page of an app? I'm assuming here that the startup bottlenecks are things like reading the locale database and reading from the app's indexedDB, and not the time it takes to populate HTML templates or instantiate web components.
• Given that the service worker cache is based on the same db technology that IndexedDB is, why do we think that a server worker based render cache will be any faster than having an app just do its own caching in its own database? IIRC, the email app was the first to use this HTML caching technique, and it had to store the HTML in a cookie to get fast enough startup performance. Do we need to be talking to gecko engineers about some kind of super-fast startup cache? Maybe we need the cache built into gecko instead of into a service worker so that gecko can be retrieving our cached data even before the service worker has started up.
• Given that the new security model calls for privileged hosted apps to be in packages and the packages to be stored in the HTTP cache, do we have too many layers of caching? Will privileged gaia apps even need to use a service worker to be offline capable, or can we just replace the old app: packages with the new http: packages and continue to run as we do today with no service worker at all?
• Render cache complex use cases:
  • 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?

Initial library clients

The first clients for these libraries will be the Gaia Music and Sms apps. However we should also provide an independent and standalone hosted app example to show and document the usage of the helpers to be created. The current proposal is to create a TODO app.

Performance

• 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?

Tools

Debugging

Help designing, implementing and testing developer tools related to Service workers.

Build

We need to create a tool to allow the prepopulation of a service worker cache.

Scrum

Sprints

• Sprint 1 (May 15)
• Sprint 2 (May 29)
• Sprint 3 (Jun 12)

Bugs

Meta bug

Full Query

ID	Summary	Component	Resolution	Assigned to	Depends on	Blocks	Whiteboard	Blocking b2g	Feature b2g	Target milestone
1172869	Implement a single API to deal with window.open() scenarios	DOM: Service Workers				1153312		---	---	---

1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Code

• ServiceWorkerWare
• Offliner

The team

• Fernando Jiménez [:ferjm] <fernando@mozilla.com>
• Francisco Jordano [:francisco] <francisco@mozilla.com>
• Johan Lorenzo [:jlorenzo] <jlorenzo@mozilla.com>
• Salvador de la Puente [:salva] <salvador.delapuentegonzalez@telefonica.com>

Meetings

When

• Daily meetings happening on IRC currently on channel #gaia at 12:00 CET

Where

• B2G vidyo room.
• Public Vidyo link: https://v.mozilla.com/flex.html?roomdirect.html&key=2FCZj4WaeeMQ
• Etherpad: https://etherpad.mozilla.org/service-worker
• IRC: #b2g #gaia

What

Meeting notes:

• Gaia/Toolkit/Service Worker/Meetings/2015-04-09-KickOff
• Gaia/Toolkit/Service Worker/Meetings/2015-04-10-KickOffFollowUp
• Gaia/Toolkit/Service Worker/Meetings/2015-04-16
• Gaia/Toolkit/Service Worker/Meetings/2015-04-23
• Gaia/Toolkit/Service Worker/Meetings/2015-04-30