Clarify components/README about when to create a component.

components/README

-This directory is for features that are intended for reuse across multiple
-embedders (e.g., Android WebView and Chrome).
+This directory is for features that are intended for reuse. Example use cases:
+-code that is shared by Chrome on iOS and other Chrome platforms (since the iOS
+  port doesn't use src/chrome)
+-code that is shared between multiple embedders of content (e.g., Android
+  WebView and Chrome)
+-code that is shared between Blink and the browser process (since code in the

[blundell, 2016/07/21 08:46:56]

It looks like //content/browser includes lots of stuff from
//third_party/WebKit. Are those all problematic inclusions?

Until recently, //content couldn't depend on //components at all. Now that
Mandoline doesn't exist, what is the use case for having //content depend on
//components? 

(I know we had similar discussions recently, but the current and intended
dependency structure between //components, //content, and //third_party/WebKit
is still not clear in my head after those discussions).

[jam, 2016/07/21 15:19:59]

Those are fine. We can include POD structs that are sent over IPC say. Also
enums and definitions of mojo interfaces. see comment in
https://cs.chromium.org/chromium/src/content/browser/DEPS?rcl=0&l=51

The main point is that we don't run WebKit there. This saves us from loading
chrome_child.dll in the browser process.
There's an updated comment in
https://cs.chromium.org/chromium/src/content/DEPS?rcl=0&l=24, does that help?

Basically as we create generic mojo services, content can depend on them. this
is a step the demodularization of content. as an example, content can depend on
the generic leveldb service which is what the the new localstorage
implementation is built upon.

+  browser doesn't use Blink, while Blink doesn't include content or chrome to
+  avoid circular dependencies)
+
+In general, if some code is used by component "foo" and things above "foo" in

[blundell, 2016/07/21 08:46:56]

I find this comment ambiguous: when you say 'component "foo"', do you mean in
the sense of //components/foo or do you mean 'component' in a more general
sense? I'm not sure what this is intended to clarify given the quite concrete
guidelines you're adding above.

[jam, 2016/07/21 15:19:59]

I meant in a general sense.

[jam, 2016/07/21 15:23:09]

I renamed this from "component" to directory, to make it less ambiguous.

+the dependency tree, the code should probably live in "foo".
 
 By default, components can depend only on the lower layers of the Chromium
-codebase(e.g. base/, net/, etc.). Individual components may additionally allow
+codebase (e.g. base/, net/, etc.). Individual components may additionally allow
 dependencies on the content API and IPC; however, if such a component is used
 by Chrome for iOS (which does not use the content API or IPC), the component
 will have to be in the form of a layered component
 (http://www.chromium.org/developers/design-documents/layered-components-design).
 
 Components that have bits of code that need to live in different
 processes (e.g. some code in the browser process, some in the renderer
 process, etc.) should separate the code into different subdirectories.
 Hence for a component named 'foo' you might end up with a structure
 like the following (assuming that foo is not used by iOS and thus does not
@@ skipping 14 matching lines @@
 to illustrate process, e.g. 'browser' or 'renderer':
 
 components/foo/android/OWNERS, DEPS
 components/foo/android/java/src/org/chromium/components/foo/browser/
 components/foo/android/javatests/src/org/chromium/components/foo/browser/
 
 Code in a component should be placed in a namespace corresponding to
 the name of the component; e.g. for a component living in
 //components/foo, code in that component should be in the foo::
 namespace.