More docs.

doc/_layouts/page.html

@@ -69,6 +69,7 @@
       </script>
       <section id="main_content" class="inner">
         {{ content }}
+        <div style="clear: left;"></div>
       </section>
     </div>
 

doc/index.md

@@ -24,7 +24,7 @@ embedded as pointers. Pointers are offset-based rather than absolute so that mes
 position-independent. Integers use little-endian byte order because most CPUs are little-endian,
 and even big-endian CPUs usually have instructions for reading little-endian data.
 
-**_Doesn't that back backwards-compatibility hard?_**
+**_Doesn't that make backwards-compatibility hard?_**
 
 Not at all! New fields are always added to the end of a struct (or replace padding space), so
 existing field positions are unchanged. The recipient simply needs to do a bounds check when
@@ -34,7 +34,7 @@ always knows how to arrange them for backwards-compatibility.
 **_Won't fixed-width integers, unset optional fields, and padding waste space on the wire?_**
 
 Yes. However, since all these extra bytes are zeros, when bandwidth matters, we can apply an
-extremely fast compression scheme to remove them. Cap'n Proto calls this "packing"; the message,
+extremely fast compression scheme to remove them. Cap'n Proto calls this "packing" the message;
 it achieves similar (better, even) message sizes to protobuf encoding, and it's still faster.
 
 When bandwidth really matters, you should apply general-purpose compression, like
@@ -59,10 +59,10 @@ Glad you asked!
   process can be just as fast and easy as calling another thread.
 * **Arena allocation:** Manipulating Protobuf objects tends to be bogged down by memory
   allocation, unless you are very careful about object reuse. Cap'n Proto objects are always
-  allocated in an "arena"; or "region"; style, which is faster and promotes cache locality.
+  allocated in an "arena" or "region" style, which is faster and promotes cache locality.
 * **Tiny generated code:** Protobuf generates dedicated parsing and serialization code for every
   message type, and this code tends to be enormous. Cap'n Proto generated code is smaller by an
-  order of magnitude or more.
+  order of magnitude or more.  In fact, usually it's no more than some inline accessor methods!
 * **Tiny runtime library:** Due to the simplicity of the Cap'n Proto format, the runtime library
   can be much smaller.
 
@@ -73,16 +73,4 @@ version 2, which is the version that Google released open source. Cap'n Proto is
 years of experience working on Protobufs, listening to user feedback, and thinking about how
 things could be done better.
 
-I am no longer employed by Google. Cap'n Proto is not affiliated with Google or any other company.
-
-**_Tell me about the RPC system._**
-
-_As of this writing, the RPC system is not yet implemented._
-
-Cap'n Proto defines a [capability-based](http://en.wikipedia.org/wiki/Capability-based_security)
-RPC protocol. In such a system, any message passed over the wire can itself contain references to
-callable objects. Passing such a reference over the wire implies granting the recipient permission
-to call the referenced object -- until a reference is sent, the recipient has no way of addressing
-it in order to form a request to it, or even knowing that it exists.
-
-Such a system makes it very easy to define stateful, secure object-oriented protocols.
+I no longer work for Google. Cap'n Proto is not affiliated with Google or any other company.

doc/install.md

@@ -15,8 +15,9 @@ many essential features:
 * **Stability:** The Cap'n Proto format is still changing. Any data written today probably won't
   be understood by future versions. Additionally, the programming interface is still evolving, so
   code written today probably won't work with future versions.
-* **Performance:** While already beating the pants off other systems, Cap'n Proto has not yet
-  undergone serious profiling and optimization.
+* **Performance:** While Cap'n Proto is inherently fast by design, the implementation has not yet
+  undergone serious profiling and optimization.  Currenlty it only beats Protobufs in realistic-ish
+  end-to-end benchmarks by, like, 2x-5x.  We can do better.
 * **RPC:** The RPC protocol has not yet been specified, much less implemented.
 * **Support for languages other than C++:** Hasn't been started yet.
 
@@ -56,8 +57,8 @@ code without instructions.  It also supports continuous builds, where it watches
 changes (via inotify) and immediately rebuilds as necessary.  Instant feedback is key to
 productivity, so I really like using Ekam.
 
-Unfortunately it's very much unfinished.  It works (for me), but it is very quirky.  It only works
-on Linux, and is best used together with Eclipse.
+Unfortunately it's very much unfinished.  It works (for me), but it is quirky and rough around the
+edges.  It only works on Linux, and is best used together with Eclipse.
 
 The Cap'n Proto repo includes a script which will attempt to set up Ekam for you.
 
@@ -65,8 +66,8 @@ The Cap'n Proto repo includes a script which will attempt to set up Ekam for you
     cd capnproto/c++
     ./setup-ekam.sh
 
-If all goes well, this downloads the Ekam code into `.ekam` and adds some symlinks under src.
-It also imports the [Google Test](https://googletest.googlecode.com) and
+If all goes well, this downloads the Ekam code into a directory called `.ekam` and adds some
+symlinks under src.  It also imports the [Google Test](https://googletest.googlecode.com) and
 [Protobuf](http://protobuf.googlecode.com) source code, so you can compile tests and benchmarks.
 
 Once Ekam is installed, you can do:

doc/otherlang.md

+---
+layout: page
+---
+
+# Other Languages
+
+Currently, Cap'n Proto is implemented only in C++.  We'd like to support many more languages in
+the future!
+
+If you'd like to own the implementation of Cap'n Proto in some particular language,
+[let us know](https://groups.google.com/group/capnproto)!

doc/rpc.md

+---
+layout: page
+---
+
+# RPC Protocol
+
+The Cap'n Proto RPC protocol is not yet defined.  See the language spec's
+[section on interfaces](language.html#interfaces) for a hint of what it will do.
+
+Here are some misc planned / hoped-for features:
+
+* **Shared memory IPC:**  When instructed to communicate over a Unix domain socket, Cap'n Proto may
+  automatically negotiate to use shared memory, by creating a temporary file and then sending a
+  file descriptor across the socket.  Once messages are being allocated in shared memory, RPCs
+  can be initiated by merely signaling a [futex](http://man7.org/linux/man-pages/man2/futex.2.html)
+  (on Linux, at least), which ought to be ridiculously fast.