Labs/F1/Modularity
Background and Browser Web Modules
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 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.
F1 will be the proving ground for WebMods. Thus, the complete WebMod architecture is described here.
Architecture
Mental model
While this is obvious, it is important - we need to move to a mental model of F1 using "apps", of which there are many available even though the average user may only have a few installed. Any UX issues or other considerations which arise directly from the OWA model need to be addressed in the context of OWA rather than "worked around" in F1 (in theory at least ;)
Authentication
Ideally, F1 would not get involved in authentication other than creating a window for it to happen in. The login window itself could use whatever mechanism it liked for storing the credentials (eg, in localstorage for that domain, a cookie, etc) and the service endpoint (hosted by the same domain as the login url) could read it. F1 need not make any policy decision about how and where anything related to authentication is stored.
The descriptions below attempt to define the postMessage APIs such that the above remains true while (optionally) allowing an app to support multiple concurrent accounts being used (eg, having 2 twitter accounts configured.) But this hasn't been given a huge amount of thought and needs to be carefully considered.
F1-Specific Features
Service Discovery, Installation and Storage
The F1 UI will need to make a distinction between "installed" apps and "discoverable" apps - currently this distinction doesn't really exist as the number of possible apps is assumed to be small.
The F1 server will be the primary service discovery mechanism. An end-point will be exposed to list the URL of the manifest for all apps which support our service. The service will return both the "internal" apps supported directly by F1 and any other "external" services we know about. A config file or similar will list those external services, so as (say) facebook supports this sharing directly, we make a simple change to that config file and the facebook hosted app is able to be discovered by F1.
F1 will allow the user to "install" these discovered applications. Installed apps will be kept in local-storage using the same basic model as OWA itself. The routines used internally by F1 to enumerate the installed applications should be identical to the OWA counterparts. There will need to be some UI for removing an app, which needs to be different from any UI relating to "disconnect/logout from this app service." F1 will probably relax the OWA restriction about "only one app per domain" simply so all "internal" F1 apps can be hosted together.
Other UI and Front-End Issues
The main F1 panel and related code will need to be revamped in a couple of ways: each installed app will get an invisible iframe and all UI config information will be obtained using postMessage with that iframe. ie, the F1 UI will not be able to keep a global list of "services" as it does now, but dynamically build that list by querying each of the apps. Additionally, any service specific UI (both the service specific templates currently applied to F1 and the few hard-coding of service behaviour in the javascript) will need to be removed and implemented using data obtained via the postMessage channel. This means F1 probably doubles the number of iframes in use - one invisible one for each app (pointing at the app's domain), and one visible one for each app (holding dynamically built F1 content.)
Each existing F1 service will need to be broken into its own "app" and all send and auth related functionality etc implemented in each app rather than "globally". This can probably be done simply by having each app load the same javascript module (ie, share the implementation even though it exists in different apps). The F1 server end-points for sharing probably do not need to change.
F1 postMessage APIs
Implementation Plan
Version 1 -- Hard-Wired WebMods
The primary goals of this stage are to:
- provide a long-term solution for the long-tail of F1 services in the shortest possible timeframe.
- provide an auth mechanism which is both flexible and in the direct control of the service itself (eg, avoids the need for Mozilla infrastructure to store oauth tokens to any 3rd party).
- help refine and prove certain aspects of the OWA design, including the HOWA concept.
In this stage, F1 will use an "app-like" model but will not depend on the OWA extension being installed or even the spec being finalized. Thus there will be no standard way of installing, managing or discovering apps - F1 will take special, possibly temporary, action for these.
Each supported service will be implemented as a "headless open web app" - this will be true for "external" apps hosted directly by the vendors (eg, if we can convince google/twitter to host their app) and for "internal" apps hosted by F1 (ie, for all the existing services F1 supports where the vendor is not yet on-board).
F1 will need to define the postMessage javascript API, implement it for the "internal" services and advocate for it to "external" services (hopefully overlapping, so the externals can offer feedback on the API). F1 must be implemented using just this API - the F1 UI must not have any special UI behaviour hard-coded for facebook etc - everything must be able to be expressed via the API.
In addition to the constraints above, all work must be done with an eye towards the OWA-enabled world in Stage 2. Or to put it another way, if we can't see a clear path to Stage 2, we don't really need bother working within the constraints of HOWAs in the first place.
Stage 2: Using Open Web Apps directly
The primary goals here are:
- to use the Open Web Apps specification for all "app" management - including discovery and installation of new services.
- To reuse as much of the OWA UI as possible (eg, the door-hanger) to both ensure a consistent app UX and to reduce duplicated code between F1 and OWA.
- Allow OWA to be the primary mechanism for new vendors supporting the service and the discovery of that new support.
This will depend on 2 things largely out of our control: a final spec and release of Open Web Apps, and significant uptake of this model by 3rd party external services.
At the end of this stage, F1 will look as if it had been designed and implemented *after* the HOWA spec was finalized. Eventually F1 will not host any "internal" services and the backend can be retired.