From the chromium-dev post
The (since removed) README file says:
This is an effort to extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content, such as HTML, Pepper, or NaCl.
That sounds like a fairly lofty goal. What it really boils down to is isolating the components of our multi-process architecture that are concerned with process management, sandboxing and IPC. Much of this work is / will be straightforward extraction of code that is currently part of src/content/ into a narrower submodule.
In part with this effort, we are re-thinking IPC. Chrome IPC has served us well, but we see some ways in which it could be improved:
- The IPC system should make connections between services and clients more of a first-class concept. We have a lot of code that is effectively just doing that in an ad-hoc fashion for different services.
- Related to the above, the IPC system should make it easy to move services to different threads or processes with minimal disruption to clients.
- We should have a way to machine-generate C++ bindings for IPC. Imagine if making your code callable from another process was as simple as implementing an interface. That could help with code clarity as well as enable easier/better unit and fuzz testing.
- The IPC system should make it easier to setup and pass around byte streams, shared memory and files. There is a bit of a barrier to using these things correctly in the current setup, which often results in people choosing less efficient methods of passing around data.
- The IPC system should use a messaging format that is optionally capable of being used in cases where we want to talk between end-points built from different versions of the code base. This would open up the possibility of breaking Chrome up into components that are versioned separately. (Note: We already do this to a certain extent by leveraging Pepper, but growing Pepper for these use cases is costly if the APIs are not general purpose.)
- Related to the above, we should have a binary pickling format that is more resilient to version skew. See the mess that is content/common/page_state_serialization.cc for an example of how base::Pickle is not at all the right choice for archiving data structures.
The above is just a taste of some of the benefits to be had. More details as they emerge :-)