osmose / shield-study-utils Goto Github PK

Claim: this is intended to be the source repo for ShieldStudy.jsm along with examples for doing embedded webExtension addons.

Problem Statement

Jetpack[1] (in particular, Jetpack's require, and jpm) as NOT THE PATH FORWARD.

Jetpack Problem Claims:

1. jetpack as a library is Dead (or close to it) (especially in 57+). The require
2. webExtensions aren't Enough to do (ad-hoc) Instrumented studies, for these reasons.
   a. no window-chrome general case modification
   b. telemetry pings
   c. telemetry enviroment
3. Bootstrap.js (Restartless) addons aren't going away, for PRIVILEGED AUTHORS. They are needed for system addons, etc.

Implications and engineering solution:

1. Embedded webExtension AND pure restartless are VIABLE PATHS forward.
2. The core STUDY functionality will be provided by a SINGLE-FILE cu.import jsm module.
3. CORE SHIELD FUNCTIONALITY is listed below
4. GOTCHAS/WARTS of bootstrap.js is listed below.

CORE SHIELD FUNCTIONALITY

Status: Proposed for Argument

1. Variations - Choosing variations
   a. deterministically, given clientId, variation names and proportions
   b. at Random, given names and proportions
2. Variations - Persisting variation between restart
3. Variations - Knowing: answer query about assigned variation for webExtension code
4. Telemetry (States) - telemetry for
   a. INSTALL
   b. ENDINGS (expiration, uninstall)
5. Telemetry (specific), allow addon to send study-specific telemetry
6. Population Tagging, to power dashboards
   a. STARTUP tags in telemetryEnviroment
   b. all end-of-study un-tags in telemetryEnviroment
7. (MAYBE) Survey launch at critical times (uninstall, expire, other times).
8. (MAYBE) Expiration Watcher (study uninstalls after DAYS days).

NOT PROMISED (bootstrap.js) should do these:

1. Feature startup. Think more this:

startup(data, reason) {  
   let variationName = ShieldStudy.variation;
   feature.startup(variationName);
}

2. Feature cleanup.

Unclear Engineering decisions

1. Should ShieldStudy be a singleton, or a class, and does it matter
2. how explicitly should the bootstrap.js have to do things like setWatchers, etc. Explicit is CLEAR, but makes it harder for a reviewer to check that you SET THEM ALL. There are several kinds of 'long-timers' we probably want on all the time.
3. How to test these kinds of addons.

GOTCHAS (warts?)

1. bootstrap.js should now mostly ignore install functions.
2. Cu.import for the addon-specific files need to be during / after startup.
3. tools > web developer > browser toolbox is better for debugging about:debugging. There seems to be some hairy bits that We Should Fix around bootstrap debugging (sometimes you need to uninstall / re-install. Can't uninstall from from `about:debugging, etc.).
4. Packing up your addon needs a tar/zip tool/script whatever, with no existing super-common tooling. Not jpm, not web-ext. No (yet) existing "watch and zip" functions, but something like watch might be rad.

[1] Jetpack = The Mozilla Addon-Sdk. In particular the unusual require semantics, which is not quite Node-like, but looks like it. Loading files in it also blocks the main thread, which WAY UNCOOL.