Gaia/Architecture Proposal: Difference between revisions

← Older edit

Gaia/Architecture Proposal (view source)

Revision as of 16:33, 13 April 2015

6,268 bytes added , 13 April 2015

m

no edit summary

Ferjm

Confirmed users

483

edits

@@ 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.
-== Telemetry Overview ==
+= Telemetry Overview =
 [[File:Gaia Architecture Proposal Telemetry.png]]
@@ Line 155: / Line 155: @@
 *** Custom metrics defined via the various Performance interfaces [http://mxr.mozilla.org/mozilla-central/source/dom/webidl/Performance.webidl [1<nowiki>]</nowiki>] [http://www.w3.org/TR/performance-timeline/#sec-window.performance-attribute [2<nowiki>]</nowiki>] [http://www.w3.org/TR/resource-timing/#extensions-performance-interface [3<nowiki>]</nowiki>] [http://www.w3.org/TR/user-timing/ [4<nowiki>]</nowiki>]
 * about:memory per capsule
+** Available in Gecko, need to find a way to expose it to our telemetry report.
 ** performance.memory API (chrome Only). But for now it still does not reports enough metrics to us. Basically it reports only the JS Heap size, while additional data such as DOM, CSS, Images, ... consumptions would be valuable.
 * Lags
 ** Communication lags between capsule (See the [[#Bridge|Bridge]] section for more details)
 ** Event loop lags (available in Gecko, need to find a way to expose it to our telemetry report).
-* Various other data
+* Various other reports
 ** Heatmap
 ** How many times a capsule has been used
+** ...
 Those reports, if formatted and exploited correctly could help for various types of decisions making:
@@ Line 179: / Line 181: @@
 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 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 =
 [[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.
@@ Line 215: / Line 217: @@
 === Disclaimers ===
-''Note: A fairly common mistake is to try to compare this high-level decoupling with existing framework. Those are solving orthogonal problems, and a direct comparison does not really make sense. <br /> The main idea here is to expose some of the application logic to the web browser in order to benefits from the browser internal machinery as well as being able to get low level monitoring for the exposed part of the application. <br /> This model is not about using x, y or z. It is technology agnostic and uses very basic primitives of the Web. Various technologies can be put on top of that (module UI, React, Web Components, etc.) and can actually be benchmarked with real data from users using Telemetry.
+''Note:'' A fairly common mistake is to try to compare this high-level decoupling with existing framework. Those are solving orthogonal problems, and a direct comparison does not really make sense. <br /> The main idea here is to expose some of the application structure to the web browser in order to benefit from the browser internal machinery as well as being able to get low level metrics for the exposed part of the application. <br /> This model is not about using x, y or z. It is technology agnostic and uses very basic primitives of the Web. Various technologies can be put on top of that (module UI, React, Web Components, etc.) and can actually be benchmarked with real data from users using Telemetry.
-''
+''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.
-''Note: There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartment isolation which results into exposing the app internals to the Web Browser. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provide this level of encapsulation at the moment is an <iframe>.''
+In order to protect developers from mistakes, views will run into a sandbox that won't let them access this wrapper directly.
 === Features ===
@@ Line 243: / Line 274: @@
 [[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.
@@ Line 266: / Line 297: @@
 The clients can call remote methods on the server, and can subscribe to events. The server API is defined in a separated strict contract file.<br />
-The client does not need to know who is going to resolve the contract. As a result servers can either be Windows, Workers, SharedWorkers or even a ServiceWorker.
+None of the sides needs to know what is the context that runs the code of the other side. So the client does not need to know who is going to resolve the contract, nor the server needs to known who are its clients.
-It can also be used by a Worker (as a Client) to access Main-thread only WebAPIs via the bridge channel.<br />
+As a result clients and servers can either be Windows, Workers, SharedWorkers or ServiceWorkers.
-The contract defined between a client and a server define the methods and events available, has strong types, offer a place to record the communication for debugging purpose, can measure the latency of responses and fire a telemetry report, ...
+The bridge can also be used by a Worker (as a Client) to access Main-thread only WebAPIs.
+The contract defined between a client and a server define the methods and events available. The contract is built with a few additional features:
+* Strong types
+* debug mode
+* Communication recording for debugging purpose
+* Method calls latency
+* ...
 The contract for a specific service can have multiple versions in order to allow older clients to works with the newly server code.
@@ Line 298: / Line 336: @@
 ''
-Note: The contract resolution is asynchronous since the server may not run when the client asks for a service. But the API is abstracting that so you can call methods even if the server is not running yet.''
+Note: The contract resolution is asynchronous since the server may not run when the client asks for a service. But the API is abstracting that so developers can call methods even if the server is not running yet.''
 Server side usage example:
@@ Line 324: / Line 362: @@
 === Front-End / Back-end. Multiple Windows ===
-While on low-end devices most of the application will be shutdown when the application is in background, on high-end devices memory is not the big bottlenext anymore and so we can favor the user experience.
+While on low-end devices most of the application will be shutdown when the application is in background, on high-end devices memory is less a bottleneck and so it sounds a good tradeoff to consume more memory in order to favor the user experience.
 In such cases, if the application is already opened in the background, and the user opens a bookmark to a specific panel, starts a WebActivity resolving to the app, etc.., there is no need to restart the whole application logic, the bridge will just connect the 2 windows in a transparent fashion.
@@ Line 333: / Line 371: @@
 = Memory Management =
-While one of the goal of this architecture is to free the main thread (using it UI related tasks only), and to share the related logic for instant bookmarks, actions, activities, there may be times where the memory limitations of the device are the bottleneck.
+While one of the goal of this architecture is to free the main thread (using it for UI related tasks only), and to share the related logic for instant bookmarks, actions, activities, there may be times where the memory limitations of the device is a bottleneck.
-For such devices, the model offers a macro memory management. So when the application goes in background, most of the non user-facing parts (in red here) can be shutdown safely in order to recover memory.
+For such devices, the model offers a macro memory management. So when the application goes in background, most of the non user-facing parts (in red here) can be shutdown safely in order to recover as much memory as we can.
-Then, when the app is coming back to foreground, those can be restored to maximize the user-experience.
+Then, when the app is coming back to foreground, those non user-facing parts can be restored to maximize the user-experience.
 [[File:Gaia Architecture Proposal App Architecture Background WithWebAPIs.png|400px]]
@@ Line 365: / Line 403: @@
 = Back-End as Services =
-The hard split between the front-end and the back-end will let us explore alternative models, where both can runs onto separate processes, using the same bridge abstractions.
+The hard split between the front-end and the back-end will let us explore alternative models, where both can runs onto different processes, using the same bridge mediator code.
+''
+Note: A new WebAPI is needed to allow cross-origin communication safely and efficiently, and in order to open those Services to third-party app. In the meantime this can be prototype for default apps only, in order to see how it behaves.''
 == One front-end / One Service ==
@@ Line 377: / Line 418: @@
 == Multipe front-ends / Multiple services ==
 Since the back-end is the one responsible to manage applications data, the same set of data can be shared across multiple front-ends.
+As a result it can be multiple application, displaying user datas in various ways, running at the same time.
 [[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].