From: W. Trevor King <wking@tremily.us>
Date: Thu, 30 Aug 2012 03:57:05 +0000 (-0400)
Subject: doc:tutorial: document `be serve-storage`.
X-Git-Tag: 1.1.0~108
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=fad4a92f93d3ad2d798521735c8f83827107d603;p=be.git

doc:tutorial: document `be serve-storage`.
---

diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 7e801e7..4b3b84d 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -368,18 +368,32 @@ BE over HTTP
 Besides using BE to work directly with local VCS-based repositories,
 you can use::
 
-    $ be serve
+    $ be serve-storage
 
 To serve a repository over HTTP.  For example::
 
-    $ be serve > server.log 2>&1 &
+    $ be serve-storage > server.log 2>&1 &
     $ be --repo http://localhost:8000 list
 
 Of course, be careful about serving over insecure networks, since
 malicous users could fill your disk with endless bugs, etc.  You can
-dissable write access by using the ``--read-only`` option, which would
+disabled write access by using the ``--read-only`` option, which would
 make serving on a public network safer.
 
+Serving the storage interface is flexible, but it can be inefficient.
+For example, a call to ``be list`` against a remote backend requires
+all bug information to be transfered over the wire.  As a faster
+alternative, you may want to serve your repository at the command
+level::
+
+    $ be serve-commands > server.log 2>&1 &
+    $ be --server http://localhost:8000 list
+
+Take a look at the server logs to get a feel for the bandwidth you're
+saving!  Serving commands over insecure networks is at least as
+dangerous as serving storage.  Take appropriate precautions for your
+network.
+
 Driving the VCS through BE
 --------------------------