Clarify components/README about when to create a component.

components/README

Index: components/README
diff --git a/components/README b/components/README
index 8112f6e25d7d1e750c27bd7c4b97482184259af8..de3c8e1e2f1fff2de6e89a7d449d96e518f7d17b 100644
--- a/components/README
+++ b/components/README
@@ -1,8 +1,17 @@
-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