The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

The Chromium OS designs and code are preliminary. Expect them to evolve.
For Developers‎ > ‎Content module‎ > ‎

Content API

Motivation

  • isolate developers working on Chrome from inner workings of content
  • make the boundary between content and chrome clear to developers and other embedders

Goal

  • All of content implementation would be under src/content/src
  • Embedder API would be under src/content/public
  • DEPS rules would prevent chrome from reaching to the implementation files

Design

In general, we will follow the design of the WebKit API. This makes it easier for people who're already familiar with it, and also keeps things consistent.
  • all interfaces should be in the "content" namespace
    • After we're done with separating content from chrome, we will move all the implementations to the content namespace as well, which is the guideline for all code apart from src/chrome. The content implementation will also move to content/src.
  • interfaces that content implements should usually all be pure abstract, because usually there's only one implementation
  • interfaces that embedders implement, especially ones which are used in tests or are observer-style and have many implementations, should have default values
  • enum values should start with the name of the type, i.e. PAGE_TRANSITION_LINK in the content::PageTransition enum
  • content implementation code should use other implementations directly and not go through the interface (i.e. code in content/renderer should use RenderViewImpl instead of content::RenderView)
  • it's acceptable to put implementation files that hold constructors/destructors of interfaces/structs which might have member variables. For structs, this covers initializing member variables. For interfaces (i.e. RenderViewObserver) this might cover things like automatic registration/unregistration. Normally we would put this small code in headers, but because of the clang checks against putting code in headers, we're forced to put it in .cc files (we don't want to make a clang exception for the content/public directory since that would lead to confusion).
  • when code in chrome implements an interface from content, usually the convention is to prefix the implementation with "Chrome" (i.e. ChromeContentBrowserClient derives from content::ContentBrowserClient)
  • since by design any file in chrome can include files in content/test, we never want to leak content implementation headers in test file headers, as that would give chrome code access to content implementation files.
  • only expose methods in the public API that embedders need. If a method is only used by other code in content, it belongs in Ximpl.h and not X.h.

Plan

  • Start moving existing content APIs to src/content/public. All the interfaces will be under the content namespace. This includes:
    • embedder escape hatches: ContentClient, ContentBrowserClient, ContentRendererClient, ContentPluginClient, ContentUtilityClient
    • feature-specific escape hatches: ResourceDispatcherHostDelegate, DownloadManagerDelegate, ContentMainDelegate, BrowserMainParts
    • profile object on UI/IO threads: BrowserContext, ResourceContext,
    • observer classes: RenderViewObserver, RenderProcessObserver, RenderViewHostObserver, TabContentsObserver, BrowserMessageFilter
    • original Chrome interfaces: RenderWidgetHostView, TabContentsView, TabContentsDelegate
  • Create interfaces around existing core objects and convert Chrome code to use them. This includes things like:
    • browser process: BrowserRenderProcessHost, RenderViewHost, RenderWidgetHost, TabContents, BrowserChildProcessHost, PluginService, BrowserThread, DownloadManager, DownloadFile, DownloadItem, DownloadManager, etc...
    • renderer: RenderView, RenderWidget, RenderThread, RenderProcess, etc...
    • child processes: ChildProcessHost, ChildThread
  • Move all the current content implementation code from src/content to src/content/src
For existing classes that are not interfaces, this is the process we will follow (using RenderView as an example). The goal is to keep file moves and updating of includes to a minimum.
  1. Create content::RenderView interface in src/content/public/renderer/render_view.h
  2. Convert all existing usage of RenderView from all modules above content (i.e. chrome, chrome_frame) layer to use content::RenderView in stages
  3. Move RenderView from src/content/renderer/render_view to src/content/src/renderer/render_view_impl.h (renaming the class to content::RenderViewImpl)

Sign in|Report Abuse|Print Page|Remove Access|Powered By Google Sites