Labs/F1/Modularity: Difference between revisions

Jump to navigation Jump to search

Labs/F1/Modularity (view source)

Revision as of 22:13, 3 June 2011

2,589 bytes removed ,  3 June 2011
→‎F1-Specific Features
Line 47: Line 47:
* 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.
* 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, ..)
* 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-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 WebMod APIs ==
== F1 WebMod APIs ==
BenAdida
668

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/315405"

Navigation menu