remove serve-storage and HTTP storage driver

This functionality is now better fulfilled by using an off-the-shelf network
file system technology to share the BE object directory. This has the advantage
of a more comprehensive and integrated security model as well.

1 files changed, 3 insertions, 23 deletions

diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 443ac2a..3a1b8e8 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -372,33 +372,13 @@ BE over HTTP
 ------------
 
 Besides using BE to work directly with local VCS-based repositories,
-you can use::
-
-    $ be serve-storage
-
-To serve a repository over HTTP.  For example::
-
-    $ 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
-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::
+you can serve your repository over HTTP 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.
+Serving commands over insecure networks can be dangerous. Take
+appropriate precautions for your network.
 
 Driving the VCS through BE
 --------------------------