Add some docs about mojom (files/IDL).

docs/intro/message_pipes.md

 # Message pipes
 
 Message pipes are the primary communication mechanism between Mojo programs. A
 *message pipe* is a point-to-point (with each side being called a message pipe
 *endpoint*), bidirectional message passing mechanism, where messages may contain
 both data and Mojo handles.
 
 It's important to understand that a message pipe is a "transport": it provides a
 way for data and handles to be sent between Mojo programs. The system is unaware
 of the meaning of the data or of the handles (other than their intrinsic
 properties).
 
 That said, Mojo provides a *standard* way of communicating over message pipes,
-namely via a standardized protocol together with [Mojom](mojom.md) IDL files.
+namely via a standardized protocol together with [Mojom IDL](mojom_idl.md)
+files.
 
 ## Messages
 
 A *message* consists of two things:
 * a finite sequence of bytes, and
 * a finite sequence of [Mojo handles](handles.md).
 
 Both of these are determined when the message is sent (or *written*). Messages
 are *framed* in the sense that they are "atomic" units: they are sent and
 received (or *read*) as entire units, not just by Mojo programs themselves but
 by the system, which is aware of and enforces the message boundaries.
 
 (Note on terminology: We'll use "send" and "write" interchangeably, and
 similarly for "receive" and "read". "Write" and "read" correspond more closely
 to the names usually given to the basic Mojo operations, e.g.,
 `MojoWriteMessage()` and `MojoReadMessage()`.
 
 ## Asynchronous operation and queueing
 
 Message pipes are *asynchronous* in the sense that sent messages do not have
 intrinsic response messages mediated/enforced by the system. (This is different
 from saying that message write/read are asynchronous operations: these
 operations are actually synchronous and complete "immediately". However, note
 that reading a message is "nonblocking" in the sense that it will fail if a
 message is not available to be read. Thus a message must be waited for, and the
 combined wait-then-read may form an asynchronous pattern.)

[jln (very slow on Chromium), 2016/07/26 23:20:23]

didn't you mean "may form a synchronous pattern" here?

[vardhan, 2016/07/26 23:36:44]

yeah, i think synchronous pattern is right

 
 To allow message writes to complete immediately, messages are queued. Indeed,
 one can understand a message pipe as a pair of queues, one in each direction.
 Each endpoint has opposite notions of incoming and outgoing queues (recall that
 message pipes have a pair of endpoints).
 
 Writing a message to an endpoint then simply entails enqueueing that message on
 that endpoint's outgoing queue (which is the *peer* endpoint's incoming queue).
 Reading a message from an endpoint is just dequeueing a message from that
 endpoint's incoming queue (which is the peer endpoint's outgoing queue).
@@ skipping 24 matching lines @@
 
 ## "Synchronous" operation
 
 Though message pipes are asynchronous as discussed above, they may be used in a
 synchronous fashion: immediately after sending a *request* message, one can then
 just block and wait for the *response* message (and then read it and process
 it). Of course, this requires that the protocol support this:
 * Message pipes must be used in a "directional" way: there must be fixed request
   and response directions or, equivalently, one endpoint belongs to the *client*
   and the other to the *server* (or *impl*). (Historical note: This is the case
-  for the current Mojom protocol, but not in previous versions.) The issue here
-  is that without this, the sender of the request messages may have to process
-  incoming request messages from its peer.
+  for the current [Mojom protocol](mojom_protocol.md), but not in previous
+  versions.) The issue here is that without this, the sender of the request
+  messages may have to process incoming request messages from its peer.
 * Request messages must have unique response messages. (In the Mojom protocol,
   request messages have optional unique responses. For messages without
   responses, one can just proceed immediately without waiting. However, without
   response messages there may be flow control issues; again, see above.) The
   important point is that for each request message, there is a well-defined
   number of response messages for each request and not arbitrary "callback"
   messages.
 * The sending of a response message must not depend on a future action of the
   client. (This is a higher-level semantic that is not enforced by the Mojom
   protocol. E.g., one may define a Mojom interface in which the response to a
@@ skipping 11 matching lines @@
   result in deadlock. (E.g., this is the usual programming model for the
   standard Mojom C++ bindings.)
 * Even when blocking is permissible, it may not be desirable to do so:
   advancement of the program then relies on trusting the server to be
   responsive and send responses in a timely fashion.
 * Mixing asynchronous and synchronous operation is problematic: one cannot send
   a request and synchronously wait for a response while responses to other
   messages are still pending. (Theoretically, one could buffer such other
   responses until the response to particular request is received, and process
   those other responses later, but this would be dubious at best.)