I'm writing to provide a little background about the src/mojo top-level directory that was recently added.
The 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 :-)