Privileged loader architecture about webmaker-android

[thisandagain]

I love this! 🐈

I really like how similar in approach this could be for Android / iOS wrappers as well. Will start spec as part of the "Hello World" SOW.

[davidascher]

Another advantage is this architecture makes it possible for us to do A/B testing more easily -- e.g. different starter templates, and see which perform better.

[thisandagain]

After talking with some folks about this I started to shy away from the idea of loading and storing all assets from a remote bundle in IndexedDB. Couple issues that I ran into with the initial approach:

• IndexedDB does not work in webworkers (yet) (https://bugzilla.mozilla.org/show_bug.cgi?id=701634)
• Streaming blobs to IndexedDB via XHR doesn't work as you would hope, so we would need to build a buffering / queuing system which would consume memory overhead.
• Monkey patching streaming blobs from IndexedDB on each asset load feels like mad science (aka FUN!) but also like mad science (aka BUGGY!).

My proposal is to leverage the existing appcache infrastructure and simply use IndexedDB to store / track the state of updates. Updates themselves (which I'm calling "bundles") are just versioned hosted apps that the loader application downloads in the background via an iframe. Once the appcache API returns as ready, the loader application will mark it for release upon next process start. An inter-frame communication abstraction would handle exposure of privileged APIs.

Tracking here:
https://github.com/mozillafordevelopment/beaker