Labs/F1/Modularity: Difference between revisions

Jump to navigation Jump to search

Labs/F1/Modularity (view source)

Revision as of 22:18, 1 June 2011

50 bytes added ,  1 June 2011
no edit summary
No edit summary
Line 7: Line 7:
F1 will be the proving ground for WebMods. Thus, the complete WebMod architecture is described here.
F1 will be the proving ground for WebMods. Thus, the complete WebMod architecture is described here.


== Stage 1: An "app-like" model ==
== Architecture ==
 
=== 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 postMessage APIs ===
 
F1 will need to define the following javascript postMessage/jschannel based APIs (this is off-the-top-of-my-head and hoping to capture the intent rather than the actual spelling)
 
To be implemented by the app (ie, APIs called by F1)
 
getShareCharacteristics()
  Get enough metadata about the application so the necessary UI for the service can be dynamically built.  This is similar to the current F1 "services" global, and allows F1 to offer "send to wall" for facebook versus "send to my contacts" for linkedin.
 
getUserInfos()
  Return a *list* of info for each logged in user to the service.  If the list contains more than 1 item, multiple accounts against that service are being used (eg, 2 twitter accounts are configured).  The user-info will include some pre-defined fields (eg, name, username, avatar) and any other values the service desires. The full user info (including the service specific "blobs") will be passed back into the service for many future operations.
 
Optionally, the return value will include a URL which can be used for logging in.  Services which only allow one user at a time will only return that URL when the list of logged-in users is zero.  Services which allow multiple users/accounts will return this URL even when there are returned users.
 
When login is required/desired, F1 will open the popup and establish a postMessage channel between the popup and the invisible iframe, so the login screen and the application itself can directly communicate.  When login is complete, the app itself will be able to communicate this back to F1 (which will then re-execute this request and presumably get an extra user in the returned list, and adjust the UI accordingly)
 
getAutocompleteEntries(user_info, send_to, to_prefix)
  Get all the autocomplete entries for the "to" field based on the current setting of the "send to" field for the specified user.  For example, the facebook app might return the list of all groups you are a member of if send_to="group wall", and twitter would send a list of all your followers for send_to="direct".
 
send(user_info, data)
  Send an item as described by "data" - ie, perform the actual share.
 
APIs to be implemented by F1, suitable for being called by any of the services:
 
userInfoChanged()
  Inform F1 that the list of logged-in users for the app has changed. F1 will refresh the service by calling getUserInfo() and adjust itself accordingly - eg, by creating a second visible iframe for the service if a new user appears, or displaying special UI if no logins exist at all.
 
others?
 
== Deployment Plan ==
 
=== Version 1 --  Hard-Wired WebMods ===


The primary goals of this stage are to:
The primary goals of this stage are to:
Line 23: Line 62:
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.
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 ==
=== Stage 2: Using Open Web Apps directly ===


The primary goals here are:
The primary goals here are:
Line 35: Line 74:
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.
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.


== Implementation plan ==
== Implementation Plan ==


The following high-level things need to be done for stage 1
The following high-level things need to be done for stage 1
Line 56: Line 95:


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.
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.
=== 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 postMessage APIs ===
F1 will need to define the following javascript postMessage/jschannel based APIs (this is off-the-top-of-my-head and hoping to capture the intent rather than the actual spelling)
To be implemented by the app (ie, APIs called by F1)
getShareCharacteristics()
  Get enough metadata about the application so the necessary UI for the service can be dynamically built.  This is similar to the current F1 "services" global, and allows F1 to offer "send to wall" for facebook versus "send to my contacts" for linkedin.
getUserInfos()
  Return a *list* of info for each logged in user to the service.  If the list contains more than 1 item, multiple accounts against that service are being used (eg, 2 twitter accounts are configured).  The user-info will include some pre-defined fields (eg, name, username, avatar) and any other values the service desires.  The full user info (including the service specific "blobs") will be passed back into the service for many future operations.
Optionally, the return value will include a URL which can be used for logging in.  Services which only allow one user at a time will only return that URL when the list of logged-in users is zero.  Services which allow multiple users/accounts will return this URL even when there are returned users.
When login is required/desired, F1 will open the popup and establish a postMessage channel between the popup and the invisible iframe, so the login screen and the application itself can directly communicate.  When login is complete, the app itself will be able to communicate this back to F1 (which will then re-execute this request and presumably get an extra user in the returned list, and adjust the UI accordingly)
getAutocompleteEntries(user_info, send_to, to_prefix)
  Get all the autocomplete entries for the "to" field based on the current setting of the "send to" field for the specified user.  For example, the facebook app might return the list of all groups you are a member of if send_to="group wall", and twitter would send a list of all your followers for send_to="direct".
send(user_info, data)
  Send an item as described by "data" - ie, perform the actual share.
APIs to be implemented by F1, suitable for being called by any of the services:
userInfoChanged()
  Inform F1 that the list of logged-in users for the app has changed. F1 will refresh the service by calling getUserInfo() and adjust itself accordingly - eg, by creating a second visible iframe for the service if a new user appears, or displaying special UI if no logins exist at all.
others?
BenAdida
668

edits

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

Navigation menu