CMP: Correcting the Chrome layer cake

[Ben Goodger (Google)]

Chrome is composed of a number of layers. At coarse level of granularity I'll describe them as follows:

- Application (this is the Chrome application, or basically anything else built on top of the Content API)

- Platform (this is the Content layer itself, where sandboxes are created, managed, IPC routing set up, & many core platform features implemented)

- Framework (these are libraries run in sandboxed child processes, like Blink, PDF, Flash, etc).

If you think of Chrome as a portable OS, its Platform layer must provide the "system services" of that OS. A typical OS would include services for secure file system, network and other device access, a UI stack for multi-app composition, animation & input handling, a service manager brokering connections between services & creating sandboxes according to the capability requirements of those services, and on and on. Today, the Content layer provides much of this functionality. Because Chrome is a browser, Content also provides some services that are atypical for a more traditional OS, like a web view that supports navigation and a tree of frame renderers.

In this scheme, dependencies flow from Application to Platform to Framework. Considered in isolation this seems a little odd, but the reasons are largely historical. As discussed elsewhere, the Platform layer is also fairly monolithic, with imperfect separation of unrelated features.

The Content Modularization Project makes the following assertions:

- The Platform layer should be the base layer of the cake, not the middle one.

- Platform Services should be appropriately isolated from one another, speaking to each other only via public APIs.

Fixing the dependency directionality will allow us to do a bunch of cleanup, removing delegate layers that exist only to service the current system design. It will also allow us to remove pervasive assumptions about the framework that's running in a particular context, etc. Isolating services gives us an opportunity to design and defend focused APIs for coherent system services, as well as giving the ability to consider further isolation of some of them according to the security and performance needs of the product.

I'm attaching two images that show the before and after states of this work. In these drawings, each block is a "service". Defining service precisely for every platform that Chrome supports is a bit tricky, but for simplicity you can think of it as an application process that provides a set of related APIs. A defining characteristic of a service is it that it has a unique identity which can be used to connect to it from another service without additional context. Service creation & lifetimes are managed by the Shell (the service manager) which is itself a service.

We've created a new toplevel directory //services which is intended to be the home of the services forming the Platform layer of the system. As we decompose the Content layer, a lot of code will end up here. //services is not intended to host subdirectories for every individual interface or small collection of related interfaces. It's helpful to think of process-level granularity for services, even if we don't create separate processes for them on all platforms. For library code shared by multiple services, some other place in the source tree remains more appropriate (e.g. //components, //ui, //base, etc depending on what the code does).

-Ben