http://www.chromium.org/developers/content-module

高レベル全体像

コンテントモジュールはsrc/contentにある。マルチプロセスサンドボックスアーキテクチャでページをレンダリングする中核コードである。HTML5やGPU加速などすべてのウェブプラットフォームの機能をもつ。Chromeの機能はもっていない（例えばextensions/autofill/spellingなどの）。目的は誰が利用してもブラウザ機能を提供できることである。

動機

Chromiumコードが大きくなるにつれ、ある種の機能は避けがたくあるべき場所でないところに釘付けにされてきた。その結果レイヤ構造は乱れ、あるべきでない依存性が存在した。開発者にとって何がベストな配置なのかを決定するのは難しいが、結局Chromeの中核コードはsrc/contentに置くことに決まった。コンテントはchromeじゃない

コンテント VS chrome

上述のように、コンテントはレンダリングのための中核コードのみ持つべきである。ChromeはAPIでコンテントを利用し、IPCでイベントを受け取る。どのように新機能を追加するか?にやり方が書いてある。

以下がChromeだけが持つ機能（大雑把に）でコンテントにはない。つまりコンテントはこれらのことを知っていてはいけない。

• Extensions
• NaCl
• ChromeFrame
• SpellCheck
• Autofill
• Sync
• Prerendering
• Safe Browsing
• Translate

アーキテクチャダイアグラム

上図はモジュール間の構造。モジュールは下位のモジュールを含むことができるが上位のモジュールは含むことができない。これはDEPSルールで強制される。モジュールは組み込み用APIを提供でき、下位モジュールはこれらをコールできる。

コンテントAPI

コンテントAPIはコンテントコードがChromeを間接的にコールするための仕組み。Chromeの機能（feature）はIPCをフックすることで実現する。 （RenderView RenderViewHost WebContentsを肥大化させずにどのように新しい機能を追加するか?）。コンテキストが充分でない場合（WebKitからのコールバックなど）やコールバックが一度しか呼ばれない場合(one-off）は、組み込み者（Chrome）が組み込んだContentClientインタフェース経由で行う。ContentClientはすべてのプロセスで利用できる。幾つかのプロセスは自分専用のコールバックAPIをもつ（ContentBrowserClient/ContentRendererClient/ContentPluginClientなど）。

現状と道筋

現状コンテントはChromeに全く依存していない（メタなバグとそれに依存するバグ参照）。コンテントは基本的にブラウザでありそれを簡潔に利用する（"content_shell"）はすべてのプラットフォームでページをレンダリングする機能を提供する。ウェブプラットフォームのテストするときもchromeを用いる必要はない。

contentのユニットテストのためにcontent_unittestsターゲットがある。統合されたテストとしてcontent_browsertestsもある。

contentは分離されたdllとしてビルドされる。ビルド高速化のため。

WebKit APIと同様にcontentのためのAPIがある。組み込み者が内部の作業を知ることなくcontentを利用できる。