Announcing the Content Modularization Project
Ben Goodger (Google)
Team,
TL;DR:
We’re kicking off an effort to incrementally decompose the Content layer into modular “services,” with clearer boundaries and defensible APIs. In the very long term, the monolithic Content layer will cease to exist.
Details:
A little over 5 years ago, we began a project[1] to extract Chrome’s multi-process architecture from the browser UI, creating the Content API. This modularization drive gave us a lot - including a new class of Web-enabled Chromium-derived applications.
Meanwhile, Chrome has grown substantially, with many new browser features. While the Content refactor made substantial progress in simplifying the code, it remains a very complex monolithic layer in its own right. It is the single bottleneck through which almost all features must pass. There is too much going on in this layer, complexity that ultimately impacts the types of development work we as a team can pursue. We are very interested in reducing this complexity.
Last year a few of us conducted an experiment called Mandoline to develop a modular browser shell based on a service-oriented architecture. In the process we convinced ourselves[2] that this was viable, and figured out how we might incrementally move src/content and src/chrome to this kind of setup.
With that as the backdrop we’d like to announce a new effort: the Content Modularization Project, with a charter to coordinate the further decomposition of Chrome & Content. This project encompasses all features, and contributors to it will work with feature teams across Chrome to evolve core code. In the long term (several years), our vision is that Content will be entirely modularized to the point where it may cease to exist as a distinct layer in Chrome. Those working on the modularization effort will figure out how to get us there, including identifying opportunistic projects that help & their priorities.
This effort is facilitated in large part by the transition to Mojo, Chrome’s new IPC tool. In the near term we are working on quickly migrating Chrome to Mojo. You have heard already from Ken Rockot[3] on that, and will hear more as the conversion proceeds. Mojo is already usable for new features. Some of our early modularization efforts are focused on the UI/Rendering stack (“Mus”), and specific platform features like Local Storage and soon Network.
John has put together a doc[4] that describes the context for this work in more detail, and some of the projects we have in mind. Please check it out. We’ll also organize a talk in the near future that goes into some more detail about what we aim to do. If any of this resonates with you and you want to learn more, please let us know either directly or on chromi...@chromium.org.
-Ben & John
====
[1] Project Carnitas - Code Cleanup https://groups.google.com/a/chromium.org/d/msg/chromium-dev/X4VTnSWRasE/J8E-VTqXyvgJ
[2] Mandoline Project Summary - https://docs.google.com/document/d/1AjTsDoY6ugaykfqGLyOHYfp67hMp0tMjDbZcJ5EH9fw/edit?usp=sharing
PhistucK
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
