Gaia/Architecture Proposal: Difference between revisions

m
no edit summary
mNo edit summary
 
(10 intermediate revisions by 3 users not shown)
Line 139: Line 139:
Sometimes the cached information will be out-of-date. The specific cache eviction strategy is up to the application. A save/restore API will be exposed to any specific views, and it is up to the view logic to manage its own cache.
Sometimes the cached information will be out-of-date. The specific cache eviction strategy is up to the application. A save/restore API will be exposed to any specific views, and it is up to the view logic to manage its own cache.


== Telemetry Overview ==
= Telemetry Overview =


[[File:Gaia Architecture Proposal Telemetry.png]]
[[File:Gaia Architecture Proposal Telemetry.png]]
Line 181: Line 181:
The encryption token is derived from Firefox Accounts in order to be shareable between multiple devices.
The encryption token is derived from Firefox Accounts in order to be shareable between multiple devices.


The remote storage back-end is not yet defined. One suggestion that is currently under investigation is to have a proxy, made by the Content Service team, offering an HTTP API in order to abstract the specificity of the remote storage back-end.
The remote storage back-end is not yet defined. One suggestion that is currently under investigation is to have a proxy, made by the Cloud Services team, offering an HTTP API in order to abstract the specificity of the remote storage back-end. You can find additional information about this service at [[Firefox_Cloud|Firefox Cloud]]


= High Level App Overview =
= High Level App Overview =
[[File:Gaia Architecture Proposal High Level App Overview.png]]
[[File:Gaia Architecture Proposal High Level App Overview.png]]


Application front-end and application back-end are independent pieces of code. And so the application front-end and the application back-end lives onto different repositories.
Application front-end and application back-end are independent pieces of code. And so the application front-end and the application back-ends will live in different repositories.


Application back-end and application front-end are both a set of capsules with strong encapsulations.
Application back-end and application front-end are both a set of capsules with strong encapsulations.
Line 220: Line 220:


''Note:'' There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartmentalization, enabling us to expose the app structure (which ''View'' is displayed? which ''View'' is under active use, which ''View'' will be displayed next...) to the engine. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provides this level of encapsulation today is an <iframe>. ''And they're cheap!''
''Note:'' There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartmentalization, enabling us to expose the app structure (which ''View'' is displayed? which ''View'' is under active use, which ''View'' will be displayed next...) to the engine. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provides this level of encapsulation today is an <iframe>. ''And they're cheap!''
=== Content Wrapper ===
The Content Wrapper is a container that hold all views. It is responsible for basic tasks such as transitioning between views.
Its existence is tied to the lack of APIs to achieve the mentioned encapsulation without a container. If the platform offers enough APIs, the Content Wrapper will go away.
It offers a simulated browser in order to support the ability to prototype:
* Page Transition API shim
* Behavior of Views
** View is unloaded and forgotten when it is leaved
** View is unloaded and put in the [https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching Back-Forward Cache] when it is leaved
** View is running in the background competing on the event loop
** View is running in the background deprioritized on the event loop
* Single point of coordination for the the bridge
** Error reporting for Servers
* Unbreakable navigation on capsule errors
* Custom pre-rendering support
* Multiple layouts with one entry point
* Unified navigation between user visible capsules of multiple apps
* ...
Once those are figured, it would be a good time to get rid of the Content Wrapper.
As a result, it should not be used to store shared logic, nor shared code.
It should not be used to communicate between views, or to hold views state.
To summary, you must ignore it as much as you can while working on a particular view and focus on the view itself.
In order to protect developers from mistakes, views will run into a sandbox that won't let them access this wrapper directly.


=== Features ===
=== Features ===
Line 244: Line 274:
[[File:Gaia Architecture Proposal BackEnd Overview.png]]
[[File:Gaia Architecture Proposal BackEnd Overview.png]]


As described previously the back-end is a set of capsules, specialized to resolve specific needs. Those needs can be related to a specific panel, or the needs of an other back-end capsule.
As described previously the back-end is a set of capsules, specialized to resolve specific needs. Those needs can be related to a specific panel, or the needs of another back-end capsule.


None of the back-end code is allowed to touch the DOM. The DOM is purely own by the front-end side, and since the back-end can run in a Worker accessing the DOM directly is not an option.
None of the back-end code is allowed to touch the DOM. The DOM is purely own by the front-end side, and since the back-end can run in a Worker accessing the DOM directly is not an option.
Line 393: Line 423:


[[File:Gaia Architecture Proposal MultiApp MultiProcess MultiThread.png|600px]]
[[File:Gaia Architecture Proposal MultiApp MultiProcess MultiThread.png|600px]]
= FAQ =
== Given that we are moving from a packaged to a hosted apps model, it seems that we will be consuming more data from the network ==
Not at all. With service workers we will have the chance to dynamically cache application resources for offline usage, so once these caches are populated all the requests to fetch app resources will consume the local offline content instead of going to the network, just like it happens with packaged apps. For preinstalled apps we can do an initial population of these caches just like we did with AppCache in the early days of Gaia and so there won't be any data consumption for the initial population of the offline cache. We will have the same scenario as we have with packaged apps in this case.
Moreover, the current proposal enables us to implement a more clever updates strategy that should mean less network consumption for application updates. If we can download only the resources or even the resource diffs that changed in the server instead of downloading the whole set of application resources on each update like we currently do with packaged apps, we will be consuming far less data from the network and so the cost of updates should be drastically reduced.
== What about the security model? ==
This new architecture requires a new security model. However we are still unsure how this new model will look like. There are some ongoing work and discussions about this that you can follow on these links:
* [[Security/B2G/PermissionReview/Hostedrisks|Security Considerations & Recommendations for a hosted Gaia]]
* [[Security/B2G/PermissionReview|Permissions review]]
* [https://docs.google.com/a/mozilla.com/spreadsheets/d/1F-3jAfMPCIqTZzk-CeoK-WuHfFJp9QhEjh6cJ2nVyDE/edit#gid=0 Permissions analysis]
* [https://groups.google.com/forum/#!topic/mozilla.dev.webapi/PicfHG9Figk Proposal: TrustedCache as an alternative to signed packaged apps]
* [https://groups.google.com/forum/#!topic/mozilla.dev.webapi/pCY77YAg_i4  Proposal: Privileged Hosted Apps ]
* [https://groups.google.com/forum/#!topic/mozilla.dev.b2g/UB1CFnVy0mc  Apps and Sensitive APIs ]
* [https://groups.google.com/d/msg/mozilla.dev.gaia/TTl90CZoOvg/eaLTf_iIde4J Delta Updates vs. Signed Resources]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1036275 Support http-served packaged HTML pages/apps]
== Are there still any plans to break the apps out into their own repos, instead of having them all in the same Gaia repo ==
Yes. There is plan to break apps into [ app backend + (n * app_front_end_per_device) + toolkit repo(s)]
== Are we still going to be giving support for packaged apps? ==
We will probably be supporting packaged apps in the platform to ensure backwards compatibility for a while and we will have to have apps running the new architecture alongside packaged apps for a while in Gaia. Mostly because we may not convert all of them at once. But we should probably stop allowing new packaged apps additions to the Marketplace at some point.
== Are we considering actually having separated pages and multi page apps in the window manager, having different urls for each page. For example to have a different url for each contact? ==
Yes. Deep linking with a unique url by default is one of the goal. For now the Content Wrapper is on the way. The goal is to get rid of it asap. But we need a few new platform features to do that.
== What's the current status of the Service Workers and Cache APIs implementation in Gecko ==
The best way to get an idea of the current implementation status is to follow [https://blog.wanderview.com/sw-builds/ Ben Kelly's blog] where he regularly posts updates and custom builds with the latest patches related to Service Workers and the Cache API. Additionally, you can also check [https://jakearchibald.github.io/isserviceworkerready/ isServiceWorkersReady].
Confirmed users
483

edits