|
|
| Line 1: |
Line 1: |
| F1, aka Firefox Share, lets users share links right from their browser. Here we work to make it easy to add/remove sharing providers, even by the user. | | F1, aka Firefox Share, lets users share links right from their browser. Here we work to make it easy to add/remove sharing providers, even by the user. |
|
| |
|
| == Preamble == | | == Browser Web Module == |
|
| |
|
| F1 will move towards using "Headless Open Web Apps" (HOWA). A HOWA is almost identical to an OWA - it has a manifest and a list of supported services. When used, the OWA gets loaded into its own iframe and all communication with the OWA is via the regular postMessage channels used by all apps. The key difference is that the iframe remains hidden (meaning it can not display a UI related to the service) and instead performs actions based purely on the messages it receives - in other words, it exposes a postMessage-based javascript API rather than a UI. The lack of UI means HOWAs can only be used by services which have direct support in the browser (either directly or via an add-on) - F1 will provide this support (ie, the UI) for link-sharing services. | | F1 will move towards using Browser Web Modules (WebMod). A WebMod is based on the service-discovery portion of Open Web Apps: a WebMod has a manifest which includes a list of supported services that the browser can hook into. The WebMod gets loaded into its own iframe and communicates with the browser using regular postMessage channels. The key difference between a full-blown OWA and a WebMod is that the WebMod iframe remains hidden, meaning it has no UI. A WebMod is effectively a postMessage-based javascript API. |
|
| |
|
| [interestingly, there is no reason a single app could not be both headless and "heady" if this was communicated as part of the OWA handshake, but that is largely a distraction which can be discussed later.]
| | F1 will be the proving ground for WebMods. Thus, rather the entire WebMod architecture is described here. |
| | |
| HOWAs provide challenges around authentication that we need to address - while they can not provide UI for the execution of the service, they will need the ability to display UI, probably in a popup, for authenticating.
| |
| | |
| This document describes the (proposed) path F1 will take to get to this model.
| |
| | |
| There will be 2 distinct stages on this path:
| |
|
| |
|
| == Stage 1: An "app-like" model == | | == Stage 1: An "app-like" model == |