Move third_party/mojo/src/mojo/public to mojo/public

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 **THIS DOCUIMENT IS A WORK IN PROGRESS.** As long as this notice exists, you
 should probably ignore everything below it.
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed, but you should have a decent grasp of C++
 and be familiar with Chromium's multi-process architecture as well as common
 concepts used throughout Chromium such as smart pointers, message loops,
 callback binding, and so on.
@@ skipping 75 matching lines @@
 A message pipe is a lightweight primitive for reliable, bidirectional, queued
 transfer of relatively small packets of data. Every pipe endpoint  is identified
 by a **handle** -- a unique process-wide integer identifying the endpoint to the
 EDK.
 
 A single message across a pipe consists of a binary payload and an array of zero
 or more handles to be transferred. A pipe's endpoints may live in the same
 process or in two different processes.
 
 Pipes are easy to create. The `mojo::MessagePipe` type (see
-`/third_party/mojo/src/mojo/public/cpp/system/message_pipe.h`) provides a nice
+`/mojo/public/cpp/system/message_pipe.h`) provides a nice
 class wrapper with each endpoint represented as a scoped handle type (see
 members `handle0` and `handle1` and the definition of
 `mojo::ScopedMessagePipeHandle`). In the same header you can find
 `WriteMessageRaw` and `ReadMessageRaw` definitions. These are in theory all one
 needs to begin pushing things from one endpoint to the other.
 
 While it's worth being aware of `mojo::MessagePipe` and the associated raw I/O
 functions, you will rarely if ever have a use for them. Instead you'll typically
 use bindings code generated from mojom interface definitions, along with the
 public bindings API which mostly hides the underlying pipes.
@@ skipping 29 matching lines @@
 Before we see an example implementation and usage of the Frobinator, there are a
 handful of interesting bits in the public C++ bindings API you should be
 familiar with. These complement generated bindings code and generally obviate
 any need to use a `mojo::MessagePipe` directly.
 
 In all of the cases below, `T` is the type of a generated bindings class
 interface, such as the `frob::Frobinator` discussed above.
 
 #### `mojo::InterfacePtr<T>`
 
-Defined in `/third_party/mojo/src/mojo/public/cpp/bindings/interface_ptr.h`.
+Defined in `/mojo/public/cpp/bindings/interface_ptr.h`.
 
 `mojo::InterfacePtr<T>` is a typed proxy for a service of type `T`, which can be
 bound to a message pipe endpoint. This class implements every interface method
 on `T` by serializing a message (encoding the method call and its arguments) and
 writing it to the pipe (if bound.) This is the standard way for C++ code to talk
 to any Mojo service.
 
 For illustrative purposes only, we can create a message pipe and bind an
 `InterfacePtr` to one end as follows:
 
 ```
   mojo::MessagePipe pipe;
   mojo::InterfacePtr<frob::Frobinator> frobinator;
   frobinator.Bind(
       mojo::InterfacePtrInfo<frob::Frobinator>(pipe.handle0.Pass(), 0u));
 ```
 
 You could then call `frobinator->Frobinate()` and read the encoded `Frobinate`
 message from the other side of the pipe (`handle1`.) You most likely don't want
 to do this though, because as you'll soon see there's a nicer way to establish
 service pipes.
 
 #### `mojo::InterfaceRequest<T>`
 
-Defined in `/third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h`.
+Defined in `/mojo/public/cpp/bindings/interface_request.h`.
 
 `mojo::InterfaceRequest<T>` is a typed container for a message pipe endpoint
 that should _eventually_ be bound to a service implementation. An
 `InterfaceRequest` doesn't actually _do_ anything, it's just a way of holding
 onto an endpoint without losing interface type information.
 
 A common usage pattern is to create a pipe, bind one end to an
 `InterfacePtr<T>`, and pass the other end off to someone else (say, over some
 other message pipe) who is expected to eventually bind it to a concrete service
 implementation. `InterfaceRequest<T>` is here for that purpose and is, as we'll
@@ skipping 14 matching lines @@
 ```
 
 At this point we could start making calls to `frobinator->Frobinate()` as
 before, but they'll just sit in queue waiting for the request side to be bound.
 Note that the basic logic in the snippet above is such a common pattern that
 there's a convenient API function which does it for us.
 
 #### `mojo::GetProxy<T>`
 
 Defined in
-`/third_party/mojo/src/mojo/public/cpp/bindings/interface`_request.h`.
+`/mojo/public/cpp/bindings/interface`_request.h`.
 
 `mojo::GetProxy<T>` is the function you will most commonly use to create a new
 message pipe. Its signature is as follows:
 
 ```
 template <typename T>
 mojo::InterfaceRequest<T> GetProxy(mojo::InterfacePtr<T>* ptr);
 ```
 
 This function creates a new message pipe, binds one end to the given
 `InterfacePtr` argument, and binds the other end to a new `InterfaceRequest`
 which it then returns. Equivalent to the sample code just above is the following
 snippet:
 
 ```
   mojo::InterfacePtr<frob::Frobinator> frobinator;
   mojo::InterfaceRequest<frob::Frobinator> frobinator_request =
       mojo::GetProxy(&frobinator);
 ```
 
 #### `mojo::Binding<T>`
 
-Defined in `/third_party/mojo/src/mojo/public/cpp/bindings/binding.h`.
+Defined in `/mojo/public/cpp/bindings/binding.h`.
 
 Binds one end of a message pipe to an implementation of service `T`. A message
 sent from the other end of the pipe will be read and, if successfully decoded as
 a `T` message, will invoke the corresponding call on the bound `T`
 implementation. A `Binding<T>` must be constructed over an instance of `T`
 (which itself usually owns said `Binding` object), and its bound pipe is usually
 taken from a passed `InterfaceRequest<T>`.
 
 A common usage pattern looks something like this:
 
 ```
 #include "components/frob/public/interfaces/frobinator.mojom.h"
-#include "third_party/mojo/src/mojo/public/cpp/bindings/binding.h"
-#include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
+#include "mojo/public/cpp/bindings/binding.h"
+#include "mojo/public/cpp/bindings/interface_request.h"
 
 class FrobinatorImpl : public frob::Frobinator {
  public:
   FrobinatorImpl(mojo::InterfaceRequest<frob::Frobinator> request)
       : binding_(this, request.Pass()) {}
   ~FrobinatorImpl() override {}
 
  private:
   // frob::Frobinator:
   void Frobinate() override { /* ... */ }
@@ skipping 35 matching lines @@
 1.  The message is passed on to the receiver. In this case the receiver is
     generated bindings code, via `Binding<T>`. This code decodes and validates
     the `Frobinate` message.
 1.  `FrobinatorImpl::Frobinate()` is called on the bound implementation.
 
 So as you can see, the call to `Frobinate()` may result in up to two thread hops
 and one process hop before the service implementation is invoked.
 
 #### `mojo::StrongBinding<T>`
 
-Defined in `third_party/mojo/src/mojo/public/cpp/bindings/strong_binding.h`.
+Defined in `mojo/public/cpp/bindings/strong_binding.h`.
 
 `mojo::StrongBinding<T>` is just like `mojo::Binding<T>` with the exception that
 a `StrongBinding` takes ownership of the bound `T` instance. The instance is
 destroyed whenever the bound message pipe is closed. This is convenient in cases
 where you want a service implementation to live as long as the pipe it's
 servicing, but like all features with clever lifetime semantics, it should be
 used with caution.
 
 ## The Mojo Shell
 
@@ skipping 110 matching lines @@
 you build should probably go there. Let's create some basic files to kick things
 off. You may want to start a new local Git branch to isolate any changes you
 make while working through this.
 
 First create a new `//components/hello` directory. Inside this directory we're
 going to add the following files:
 
 **components/hello/main.cc**
 ```
 #include "base/logging.h"
-#include "third_party/mojo/src/mojo/public/c/system/main.h"
+#include "mojo/public/c/system/main.h"
 
 MojoResult MojoMain(MojoHandle shell_handle) {
   LOG(ERROR) << "Hello, world!";
   return MOJO_RESULT_OK;
 };
 ```
 
 **components/hello/BUILD.gn**
 ```
 import("//mojo/public/mojo_application.gni")
@@ skipping 39 matching lines @@
 An app that prints `"Hello, world!"` isn't terribly interesting. At a bare
 minimum your app should implement `mojo::ApplicationDelegate` and expose at
 least one service to connecting applications.
 
 Let's update `main.cc` with the following contents:
 
 **components/hello/main.cc**
 ```
 #include "components/hello/hello_app.h"
 #include "mojo/application/public/cpp/application_runner.h"
-#include "third_party/mojo/src/mojo/public/c/system/main.h"
+#include "mojo/public/c/system/main.h"
 
 MojoResult MojoMain(MojoHandle shell_handle) {
   mojo::ApplicationRunner runner(new hello::HelloApp);
   return runner.Run(shell_handle);
 };
 ```
 
 This is a pretty typical looking `MojoMain`. Most of the time this is all you
 want -- a `mojo::ApplicationRunner` constructed over a
 `mojo::ApplicationDelegate` instance, `Run()` with the pipe handle received from
 the shell. We'll add some new files to the app as well:
 
 **components/hello/public/interfaces/greeter.mojom**
 ```
 module hello;
 interface Greeter {
   Greet(string name) => (string greeting);
 };
 ```
 
 Note the new arrow syntax on the `Greet` method. This indicates that the caller
 expects a response from the service.
 
 **components/hello/public/interfaces/BUILD.gn**
 ```
-import("//third_party/mojo/src/mojo/public/tools/bindings/mojom.gni")
+import("//mojo/public/tools/bindings/mojom.gni")
 
 mojom("interfaces") {
   sources = [
     "greeter.mojom",
   ]
 }
 ```
 
 **components/hello/hello_app.h**
 ```
@@ skipping 29 matching lines @@
 
 #endif  // COMPONENTS_HELLO_HELLO_APP_H_
 ```
 
 
 **components/hello/hello_app.cc**
 ```
 #include "base/macros.h"
 #include "components/hello/hello_app.h"
 #include "mojo/application/public/cpp/application_connection.h"
-#include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
-#include "third_party/mojo/src/mojo/public/cpp/bindings/strong_binding.h"
+#include "mojo/public/cpp/bindings/interface_request.h"
+#include "mojo/public/cpp/bindings/strong_binding.h"
 
 namespace hello {
 
 namespace {
 
 class GreeterImpl : public Greeter {
  public:
   GreeterImpl(mojo::InterfaceRequest<Greeter> request)
       : binding_(this, request.Pass()) {
   }
@@ skipping 386 matching lines @@
 
 This is still a work in progress and might not really take shape until the
 Blink+Chromium merge. In the meantime there are some end-to-end WebUI examples
 in `/content/browser/webui/web_ui_mojo_browsertest.cc`. In particular,
 `WebUIMojoTest.ConnectToApplication` connects from a WebUI frame to a test app
 running in a new utility process.
 
 ## FAQ
 
 Nothing here yet!