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

diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 7e801e7f357c0132c003a55b1b901816134fdf43..4b3b84df8f856b1fa5b1e780efaefc124a5c8705 100644 (file)
--- 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
 --------------------------