Moving gRPC support interfaces out of cronet and into a new component.

components/grpc_support/README.md

Index: components/grpc_support/README.md
diff --git a/components/grpc_support/README.md b/components/grpc_support/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..9449c50d1e88a3b5be4686012a19957c55fb6cd9
--- /dev/null
+++ b/components/grpc_support/README.md
@@ -0,0 +1,14 @@
+gRPC Support
+===
+
+This directory contains the interface and implementation of the API to use
+an external network stack from gRPC. The implementation is essentially a thin
+wrapper around net::BidirectionalStream. The API specifies that the caller to
+gRPC will pass in an opaque binary blob (stream_engine) that can be used to
+created binary streams. In Chromium, this binary blob is a
+net::URLRequestContextGetter, which is used by grpc_support::BidirectionalStream
+to drive a net::BidirectionalStream.
+
+Currently Cronet (//components/cronet/ios) is the only consumer of this API,
+but eventually code inside of Chromium should be able to use gRPC by providing
+a net::URLRequestContextGetter.

[blundell, 2016/10/06 08:31:08]

Would it be worth it to make a simple test that exercises c_for_grpc.h in
Chromium-specific fashion to serve as a basic example of how to exercise the API
within Chromium? (similar in spirit to something like content_shell)

[Garrett Casto, 2016/10/06 21:58:27]

I can file a bug for this, but currently gRPC doesn't have C++ bindings that let
you use this interface (just Objective-C).