Move services/shell to services/service_manager

services/service_manager/README.md

 # Service Manager User Guide
 
 ## What is the Service Manager?
 
 The Service Manager is a tool that brokers connections and capabilities between
 and manages instances of components, referred to henceforth as “services”.
 
 The Service Manager performs the following functions:
 
 * Brokering connections between services, including communicating policies such
@@ skipping 72 matching lines @@
 and the Service Manager destroys its corresponding instance and asks the process
 to exit.
 
 #### A simple Service example
 
 Consider this simple application that implements the Service interface:
 
 **app.cc:**
 
     #include “"mojo/public/c/system/main.h”"
-    #include “"services/shell/public/cpp/application_runner.h”"
-    #include “"services/shell/public/cpp/connector.h”"
-    #include “"services/shell/public/cpp/connection.h”"
-    #include “"services/shell/public/cpp/identity.h”"
-    #include “"services/shell/public/cpp/service.h”"
+    #include “"services/service_manager/public/cpp/application_runner.h”"
+    #include “"services/service_manager/public/cpp/connector.h”"
+    #include “"services/service_manager/public/cpp/connection.h”"
+    #include “"services/service_manager/public/cpp/identity.h”"
+    #include “"services/service_manager/public/cpp/service.h”"
 
     class Service : public shell::Service {
      public:
       Service() {}
       ~Service() override {}
 
       // Overridden from shell::Service:
       void OnStart(const shell::Identity& identity) override {
       }
       bool OnConnect(shell::Connection* connection) override {
@@ skipping 322 matching lines @@
 
     TEST_F(Test, Basic) {
       mojom::SomeInterface some_interface;
       connector()->ConnectToInterface(“"mojo:service"”, &some_interface);
       base::RunLoop loop;
       some_interface->Foo(base::Bind(&QuitLoop, &loop));
       loop.Run();
     }
 
 The BUILD.gn for this test file looks like any other using the test() template.
-It must also depend on //services/shell/public/cpp:shell_test_support.
+It must also depend on //services/service_manager/public/cpp:shell_test_support.
 
 ServiceTest does a few things, but most importantly it register the test itself
 as a Service, with the name you pass it via its constructor. In the example
 above, we supplied the name “exe:service_unittest”. This name is has no special
 meaning other than that henceforth it will be used to identify the test service.
 
 Behind the scenes, ServiceTest spins up the Service Manager on a background
 thread, and asks it to create an instance for the test service on the main
 thread, with the name supplied. ServiceTest blocks the main thread while the
 Service Manager thread does this initialization. Once the Service Manager has
 created the instance, it calls OnStart() (as for any other service), and the
 main thread continues, running the test. At this point accessors defined in
 service_test.h like connector() can be used to connect to other services.
 
 You’ll note in the example above I made Foo() take a callback, this is to give
 the test something interesting to do. In the mojom for SomeInterface we’d have
 the Foo() method return an empty response. In mojo:service, we’d have Foo() take
 the callback as a parameter, and run it. In the test, we spin a RunLoop until we
 get that response. In real world cases we can pass back state & validate
 expectations. You can see real examples of this test framework in use in the
-Service Manager’s own suite of tests, under //services/shell/tests.
+Service Manager’s own suite of tests, under //services/service_manager/tests.
 
 ### Packaging
 
 By default a .library statically links its dependencies, so having many of them
 will yield an installed product many times larger than Chrome today. For this
 reason it’s desirable to package several Services together in a single binary.
 The Service Manager provides an interface **shell.mojom.ServiceFactory**:
 
     interface ServiceFactory {
       CreateService(Service& service, string name);
@@ skipping 78 matching lines @@
 to have the Service Manager start the executable itself, the second is to have
 some other executable start the process and then tell the Service Manager about
 it. In both cases, the target executable has to perform a handshake with the
 Service Manager early on so it can bind the Service request the Service Manager
 sends it.
 
 Assuming you have an executable that properly initializes the Mojo EDK, you add
 the following lines at some point early in application startup to establish the
 connection with the Service Manager:
 
-    #include “"services/shell/public/cpp/service.h”"
-    #include “"services/shell/public/cpp/service_context.h”"
-    #include “"services/shell/runner/child/runner_connection.h”"
+    #include “"services/service_manager/public/cpp/service.h”"
+    #include “"services/service_manager/public/cpp/service_context.h”"
+    #include “"services/service_manager/runner/child/runner_connection.h”"
 
     class MyClient : public shell::Service {
     ..
     };
 
     shell::mojom::ServiceRequest request;
     scoped_ptr<shell::RunnerConnection> connection(
        shell::RunnerConnection::ConnectToRunner(
             &request, ScopedMessagePipeHandle()));
     MyService service;
@@ skipping 96 matching lines @@
 Under the Hood
 Four major components: Shell API (Mojom), Shell, Catalog, Shell Client Lib.
 The connect flow, catalog, etc.
 Capability brokering in the shell
 Userids
 
 Finer points:
 
 Mojo Names: mojo, exe
 Exposing services on outbound connections