348
edits
Changes
cjones feedback
* Mac: P2 for Q1 2011
* Linux: P3 for Q1 2011
=== Performance and Resouce Goals ===
The user installs a Mozilla Marketplace application from the Android Marketplace, granting access to a superset of device APIs allowed to Mozilla apps. The user then clicks an Install button from inside this application. The Marketplace application may then initiate a background task to download the resources associated with the application, not signalling readiness until the download task is complete. A new shortcut is created on their launcher screen. When the user launches the shortcut, the application launches full-screen with instant access to the downloaded resources.
* Works with any trusted store through navigator install APIs; need UX to add trusted stores.
* granting the superset of APIs at install time is a big speedbump
* current belief is that, since these aren't APKs, no Android settings tweaks are needed
* cjones: silent update of runtime may not be possible; also, if we want Firefox to share profile with WebRT it has to be in the same .apk (q: not just the same signing key?)
==== Windows, Classic, non-Firefox user: ====
When the user launches the executable, it checks for the WebRT libraries, doesn't find them, and initiates a download; when that download completes, the application launches with normal Windows behavior.
* cjones: to support Windows uninstall behavior, we need a full install step, branding, etc.
==== Windows, Classic, Firefox user: ====
=== Change Management for Application Manifests ===
When the stub executable is bound to an application manifest, it is given the URL of the manifest. The executable WebRT is expected to apply ordinary Cache-Control rules to this manifest, and to poll it for changes when HTTP caching rules indicate that a freshness check is needed. Some coordination between WebRT and the stub may be necessary, such as (for example) when a system call must be made by the stub to respond to a request for a new capability in the manifest.
In limited cases, the user will be prompted to accept the new manifest before it becomes active. Currently, these cases are: an addition to the API capability list, a change of the application's icon, or a change of the application's name.
