Gaia/Toolkit/Service Worker/Meetings/2015-04-23

Service worker Meet-up Notes

• B2G Vidyo room (Guest link: http://j.mp/K03h7e)
• Thursdays at 18:00 CEST / 09:00 PDT
• Minutes copied to the wiki by host each week: Gaia/Toolkit/Service_Worker#What

07/16/2015

• Work week in Madrid:
  • Topics for this ww:
    • SW gecko internals.
    • Packaging.
    • Gecko updates.
    • New push implementation.
    • You can follow the notes for the week here

• SW Toolkit specific work:
  • Performance measures:
    • We have started taking measures of how SW perform in gecko. Our idea is take a initial set of measures of basic use of SW API, and compare how the performance behaves when we add the helper library.
    • For taking this measures we want to use the current tools that we have already in FirefoxOS, in this case we want to setup a Raptor instance and take measures using User Timing API.
    • We have run into the problem that the User Timing API is not totally supported in workers bug 1155761

• • Testing ServiceWorkers:
    • We have setup an initial environment to perform unit test (and integration too if needed) in the context of the ServiceWorker.
    • This work has been added to ServiceWorkerWare and has now some basic unit tests that run in Nightly and Canary.
    • Implementation
    • The testing infrastructure allows developers to use mocha and chai to write their tests. Something already used in gaia testing framework and general web development.
    • The use of another well known and useful testing framework as sinonjs is pending due to CSP enabled by default in SW in Gecko, that doesn't allow us to execute evals.

• v3 Caches system:
  • Discussion about how the 3 caches system should work.
  • Render cache:
    • We discussed about two options, generate two kind of middlewares for ServiceWorkerWare, one allowing you to modify a SW Cache with HTTP verbs (GET/POST/PUT/DELETE), and the other one is to use BroadcastChannel API to control the content of the cache.
    • We have decided to try the first option since this will be implementation agnostic, since BroadcastChannel API is only present in Gecko.
    • Another acknowledge is to implement the second option and measure which one performs better.
    • Here you can find the middleware created (with an example in the demo folder) to use as Render Cache.
    • During the implementation of this option we have found the following bug 1134325 that in Gecko fails to perform some request operations. So finally we will need to implement the BroadcastChannel option, meanwhile we can demo the concept of render cache in Canary.
    • To test the concepts of render cache with a real web app, the following example has been created: movie catalog
    • As well a branch with performance measures has been created. Going from around ~500 ms to create a page (first time no render cache) to have it ready in ~ 40ms once it's fetched from render cache.
  • Offline cache:
    • We have decided to use, so far, the simple implementation supported in SWW. But we can iterate this idea.
    • We want to keep this one despite of having pinned http cache for gaia apps, since it will make gaia apps compatible with other browsers.
  • Custom cache:
    • We didn't go for any implementation yet since this cache could conflict with the security model.
    • Some possible implementation discussed were:
      • Use push notifications to fetch new resources / clean this cache.
      • Use an external server that could serve the content and route the pages to the new server with new content.

• Questions: