Labs/F1/Modularity: Difference between revisions

From MozillaWiki
< Labs‎ | F1
Jump to navigation Jump to search
Line 55: Line 55:


== Implementation Plan ==
== Implementation Plan ==
Where will F1 get these WebMods? That will change over time.


=== Version 1 --  Hard-Wired WebMods ===
=== Version 1 --  Hard-Wired WebMods ===


The primary goals of this stage are to:
In the first release, all F1 WebMods will be hard-wired. Users will not be able to additional sharing providers, nor will they have a dashboard of WebMods. The modularity of the system will not be exposed. F1 will be self-contained, with no code dependence on Open Web Apps (the framework for WebMods). The list of available WebMods will be update-able via F1 software updates.
 
* 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.
The implementation of each Webmod will ideally be done by corresponding partners, each responsible for their WebMod. That said, if needed, we can implement the WebMods on our own and use OAuth to bridge the API calls. We may need chrome-level permissions to allow WebMods to make OAuth calls directly from Firefox.


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.
The focus of this version will be the definition and refinement of the F1-specific link-sharing WebMod API, both in parameterizing the UI and in sending the shared link and associated message. We should ensure that our generalization matches existing major providers, and ideally a few non-major ones.


=== Stage 2: Using Open Web Apps directly ===
=== Version 2 -- Installable WebMods and a WebMod Dashboard ===


The primary goals here are:
In the second version, modularity begins to be exposed to the user. Long-tail providers can advertise a manifest which triggers a Firefox "install App" dialog, which adds a new WebMod, which is then available to F1 if that WebMod advertises the appropriate link-sharing feature. Firefox also displays a dashboard of Apps, where the user can disable existing WebMods.


* to use the Open Web Apps specification for all "app" management - including discovery and installation of new services.
By this point, the manifest specification and the link-sharing API definition should be quite stable. F1 remains fully self-contained, with no separate OWA component.
* 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.
=== Version 3 -- Full OWAs ===


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.
Eventually, once Open Web Apps are ready for prime-time, the OWA functionality takes over the WebMod and App management, the dashboard, and the WebMod/App Framework that mediates communication with WebMods. F1 then focuses on purely link sharing (and potentially other types of sharing by then).

Revision as of 22:45, 3 June 2011

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. For example, the Facebook WebMod might provide the link-send, image-send, and status-update services. F1 invokes the Facebook WebMod with action link-send when the user indicates, via F1, that he wishes to share a link with Facebook friends.

When F1 wishes to access sharing providers, it uses the WebMod framework to instantiate all relevant WebMods, each into its own iframe. F1 calls into the WebMod framework using a JavaScript API, and the WebMod framework communicates with each WebMod over postMessage. The key difference between a full-blown Open Web App and a WebMod is that the WebMod iframe remains hidden: a WebMod has no UI of its own. A WebMod is effectively a postMessage-based javascript API.

F1 will be a proving ground for WebMods, but also needs to be its own product. Thus, the complete WebMod architecture is described here, with generic pieces and F1-specifics carefully separated.

Architecture

F1-webmod.png

The WebMod framework provides to F1 (and eventually to other browser features) a simple JavaScript API that mediates access to a number of service providers of a particular feature, in this case link sharing. A WebMod is defined by a manifest that includes:

  • web origin (one WebMod per origin)
  • list of features and, for each one, a URL that handles it
  • an icon

Life Cycle

When a WebMod is needed for a particular feature, the WebMod Framework (WMF):

  • creates an IFRAME and loads the prescribed WebMod URL into it.
  • when the WebMod's page is fully loaded and ready, it messages the WMF that it is ready.
  • WMF and the WebMod engage in user authentication and potentially authorization (more below).
  • WMF sends additional messages to the WebMod to fulfill the actual feature. The pattern and structure of these messages depend on the specific feature being implemented. For F1, the specifics of the API are defined below.


User Interface

In the basic WebMod scenario, each WebMod is only an API provider: all UI is handled by the feature mediator, in this case F1. WMF provides a channel between this feature mediator and the various implementor/providers of the API.

We will also consider the case of a WebMod where each provider is assigned some screen real-estate. The specifics of how the UI interactions are coordinated across the IFRAME boundary are TBD, but one aspect is clear: a WebMod with UI is a strict superset of a WebMod: authentication and authorization are still likely to require a popup to the provider's origin for trustworthiness.

Authentication

F1, or any other WMF feature mediator (e.g. image share), does not get involved in the user's authentication with the WebMod's backend server beyond coordinating the WebMod's UI needs. Specifically:

  • WMF asks the WebMod its login status.
  • the WebMod may return either
    • a user-information blob, or
    • a "need-to-login" message.
  • When WMF receives a "need-to-login" message from the WebMod, it opens up a pop-up to the WebMod's preferred login URL.
  • The WebMod is then responsible for authenticating the user however it sees fit, likely by prompting, within the dialog, for username and password.
  • Once a user has successfully logged in, the WebMod messages WMF back with an optional opaque credentials JavaScript object, which WMF stores securely. The use of credentials helps when a user wants to invoke the WebMod with different identities, e.g. two Twitter identities.
  • WMF then messages the WebMod IFRAME with a login() call including the credentials object it received and stored. The WebMod should, at this point, respond with an ok message including user identity details (display name, username, potentially a profile photo URL, ..)

F1 WebMod APIs

The specific F1 WebMod API is documented separately:

Labs/F1/Modularity/WebMod-API

Implementation Plan

Where will F1 get these WebMods? That will change over time.

Version 1 -- Hard-Wired WebMods

In the first release, all F1 WebMods will be hard-wired. Users will not be able to additional sharing providers, nor will they have a dashboard of WebMods. The modularity of the system will not be exposed. F1 will be self-contained, with no code dependence on Open Web Apps (the framework for WebMods). The list of available WebMods will be update-able via F1 software updates.

The implementation of each Webmod will ideally be done by corresponding partners, each responsible for their WebMod. That said, if needed, we can implement the WebMods on our own and use OAuth to bridge the API calls. We may need chrome-level permissions to allow WebMods to make OAuth calls directly from Firefox.

The focus of this version will be the definition and refinement of the F1-specific link-sharing WebMod API, both in parameterizing the UI and in sending the shared link and associated message. We should ensure that our generalization matches existing major providers, and ideally a few non-major ones.

Version 2 -- Installable WebMods and a WebMod Dashboard

In the second version, modularity begins to be exposed to the user. Long-tail providers can advertise a manifest which triggers a Firefox "install App" dialog, which adds a new WebMod, which is then available to F1 if that WebMod advertises the appropriate link-sharing feature. Firefox also displays a dashboard of Apps, where the user can disable existing WebMods.

By this point, the manifest specification and the link-sharing API definition should be quite stable. F1 remains fully self-contained, with no separate OWA component.

Version 3 -- Full OWAs

Eventually, once Open Web Apps are ready for prime-time, the OWA functionality takes over the WebMod and App management, the dashboard, and the WebMod/App Framework that mediates communication with WebMods. F1 then focuses on purely link sharing (and potentially other types of sharing by then).

Retrieved from "https://wiki.mozilla.org/index.php?title=Labs/F1/Modularity&oldid=315433"