348
edits
Apps/WebRT: Difference between revisions
cjones feedback
(Saving first draft) |
(cjones feedback) |
||
| Line 17: | Line 17: | ||
* Mac: P2 for Q1 2011 | * Mac: P2 for Q1 2011 | ||
* Linux: P3 for Q1 2011 | * Linux: P3 for Q1 2011 | ||
=== Performance and Resouce Goals === | === Performance and Resouce Goals === | ||
| Line 35: | Line 34: | ||
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. | 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 | * 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 | * 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: ==== | ==== Windows, Classic, non-Firefox user: ==== | ||
| Line 42: | Line 43: | ||
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. | 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: ==== | ==== Windows, Classic, Firefox user: ==== | ||
| Line 95: | Line 98: | ||
=== Change Management for Application Manifests === | === Change Management for Application Manifests === | ||
When the stub executable is bound to an application manifest, it is given the URL of the manifest. | When the stub executable is bound to an application manifest, it is given the URL of the manifest. 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. | 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. | ||