From 58cbe6f4ea6789de292e21bec3b8ea984500b9c8 Mon Sep 17 00:00:00 2001
From: Tim Kuehn <tikue@google.com>
Date: Thu, 18 Feb 2016 21:23:42 -0800
Subject: [PATCH] Update README and service macro doc comment

---
 README.md           | 14 ++++++--------
 tarpc/src/macros.rs |  9 +++++++--
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/README.md b/README.md
index f025a89..e1b87c3 100644
--- a/README.md
+++ b/README.md
@@ -53,14 +53,12 @@ fn main() {
 }
 ```
 
-The `service!` macro expands to a collection of items that collectively form an
-rpc service. In the above example, the macro is called within the
-`hello_service` module. This module will contain a `Client` type, a `Service`
-trait, and a `serve` function. `serve` can be used to start a server listening
-on a tcp port. A `Client` (or `AsyncClient`) can connect to such a service. Any
-type implementing the `Service` trait can be passed to `serve`. These generated
-types are specific to the echo service, and make it easy and ergonomic to write
-servers without dealing with sockets or serialization directly. See the
+The `service!` macro expands to a collection of items that collectively form an rpc service. In the
+above example, the macro is called within the `hello_service` module. This module will contain a
+`Client` (and `AsyncClient`) type, and a `Service` trait. The trait provides `default fn`s for
+starting the service: `spawn` and `spawn_with_config`, which start the service listening on a tcp
+port. A `Client` (or `AsyncClient`) can connect to such a service. These generated types make it
+easy and ergonomic to write servers without dealing with sockets or serialization directly. See the
 tarpc_examples package for more sophisticated examples.
 
 ## Documentation
diff --git a/tarpc/src/macros.rs b/tarpc/src/macros.rs
index b7f4e7b..e7e9ba7 100644
--- a/tarpc/src/macros.rs
+++ b/tarpc/src/macros.rs
@@ -218,17 +218,22 @@ macro_rules! impl_deserialize {
 /// # }
 /// ```
 ///
+/// There are two rpc names reserved for the default fns `spawn` and `spawn_with_config`.
+///
 /// Attributes can be attached to each rpc. These attributes
 /// will then be attached to the generated `Service` trait's
 /// corresponding method, as well as to the `Client` stub's rpcs methods.
 ///
 /// The following items are expanded in the enclosing module:
 ///
-/// * `Service` -- the trait defining the RPC service
+/// * `Service` -- the trait defining the RPC service. It comes with two default methods for
+///                starting the server:
+///                1. `spawn` starts the service in another thread using default configuration.
+///                2. `spawn_with_config` starts the service in another thread using the specified
+///                   `Config`.
 /// * `Client` -- a client that makes synchronous requests to the RPC server
 /// * `AsyncClient` -- a client that makes asynchronous requests to the RPC server
 /// * `Future` -- a handle for asynchronously retrieving the result of an RPC
-/// * `serve` -- the function that spawns the RPC server
 ///
 /// **Warning**: In addition to the above items, there are a few expanded items that
 /// are considered implementation details. As with the above items, shadowing