E10S thoughts.

e10s.md

E10S Integration

Problems

• ** Identity **

  Currently code uses == operator to identify references to the same instance and instanceof to identify type of an instance. Obvious solution to avoid duplicate wrappers (that will lead to incorrect ==) is to have unique id on each instance and registry of wrapped instances (wrapper can be removed from it once instance is destroyed).

• ** Callbacks **

  In variety of APIs users can set callbacks which are called with an argument that is an instance of certain class (Worker or Tab for example). Such callbacks will have to be called with a wrappers implementing same api as original object (But original objects are wrappers of dom elements and wrapping them once again doesn't really feels right).

• ** Mixed chrome / addon modules **

  Currently code that can run in addon or chrome process is pretty much mixed together in the same module, identifying principals and separating them into separate modules may be a very good idea.

• ** DOM **

  Many modules wrap some DOM elements, set event listeners on events and pass them around just for a few properties. Obviously listeners can't be in the different process neither they can call functions from the other process if they pass dom element to it. (Can we have an API in a functional style for registering listeners that will read some properties and then call callback on the other process with the values of that properties ?).

• ** createHandle **

  A handle can be used as property storage that are not transmitted across the process boundary, which is useful to store callbacks that have to be triggered form another process. Unfortunately all the functions properties are converted to an undefined and object properties to an empty objects {}. This would make things simple, but can be replaced by having a registry on both sides of the process.

• ** Drawing a line **

  It's very hard to define where exactly separation should take a place. Adapters / wrappers can be either created at the low XPCOM level, in which case low level APIs will have to be simplified / changed (no dom will have to be exposed) and that will cause large changes in the implementation of high level modules or wrappers can be created for the high level APIs in which case lot's of code get duplicated three times and most of it ends up running in the chrome process.

• ** Registries **

  It seems like any approach (other then promise based ?) will require some global registry of everything that is passed across processes, without Ephemeron tables all the gc work will have to be performed manually, which is a lot of work and may cause cause memory leaks (Callbacks for instance don't have destroy methods, when should we remove them from registry? Non routed handles, would have been handy but they don't seem to work).

• ** Shared scope **

  Since *-e10s-adapter.js files define 2 wrappers of the same module name collision problems are quite common in functions:

  if ("object" === typeof chrome) {
     function foo() ...
  } else {
     function foo() ....
  }       
  

• ** Exception propagation **

  Exceptions thrown by listener registered through addon.registerCall are logged in console, but exceptions are not propagated to an add-on process. This requires manual propagation boilerplate in every wrapper probably it's a good idea to alter implementation and provide exception propagation out of the box. Example of that can be found in this commit:

  • handling in add-on process
  • propagation from chrome process

• ** UI Tests **

  Many UI tests are not build using our APIs, instead they rely directly on Cc, Ci to interact with DOM. In order to test ported APIs we need to implement additional e10s compliant utility modules and build those tests on top.

Random ideas / Prior art

• Maybe we should use contentScripts for DOM / Chrome interaction ourself.
• Having functional style wrappers for all the XPCOM APIs we relay on.
• Proxy based cross process messaging.
• Communicating Event-Loop Concurrency and Distribution
• Communicating asynchronously with remote objects using promises