Minor documentation tweaks.

diff --git a/docs/architecture.txt b/docs/architecture.txt
index c0eb861160ca48f14508bc04d5e91bbc02d4d53a..aa0101d1cd047b960970a4624d53b6226407381d 100644 (file)
--- a/docs/architecture.txt
+++ b/docs/architecture.txt
@@ -1,9 +1,21 @@
+= Tahoe-LAFS Architecture =
 
-   Tahoe-LAFS Architecture
+1.  Overview
+2.  The Key-Value Store
+3.  File Encoding
+4.  Capabilities
+5.  Server Selection
+6.  Swarming Download, Trickling Upload
+7.  The Filesystem Layer
+8.  Leases, Refreshing, Garbage Collection
+9.  File Repairer
+10. Security
+11. Reliability
 
-(See the docs/specifications directory for more details.)
 
-OVERVIEW
+== Overview  ==
+
+(See the docs/specifications directory for more details.)
 
 There are three layers: the key-value store, the filesystem, and the
 application.
@@ -31,7 +43,7 @@ There are several other applications built on top of the Tahoe-LAFS
 filesystem (see the RelatedProjects page of the wiki for a list).
 
 
-THE KEY-VALUE STORE
+== The Key-Value Store ==
 
 The key-value store is implemented by a grid of Tahoe-LAFS storage servers --
 user-space processes. Tahoe-LAFS storage clients communicate with the storage
@@ -64,7 +76,7 @@ For future releases, we have plans to decentralize introduction, allowing any
 server to tell a new client about all the others.
 
 
-FILE ENCODING
+== File Encoding ==
 
 When a client stores a file on the grid, it first encrypts the file. It then
 breaks the encrypted file into small segments, in order to reduce the memory
@@ -105,7 +117,7 @@ turn them into segments of ciphertext, use the decryption key to convert that
 into plaintext, then emit the plaintext bytes to the output target.
 
 
-CAPABILITIES
+== Capabilities ==
 
 Capabilities to immutable files represent a specific set of bytes. Think of
 it like a hash function: you feed in a bunch of bytes, and you get out a
@@ -137,7 +149,7 @@ filesystem layer (described below) adds human-meaningful names atop the
 key-value layer.
 
 
-SERVER SELECTION
+== Server Selection ==
 
 When a file is uploaded, the encoded shares are sent to some servers. But to
 which ones? The "server selection" algorithm is used to make this choice.
@@ -238,7 +250,7 @@ servers.)
   long-term connections, at the expense of complexity and latency.
 
 
-SWARMING DOWNLOAD, TRICKLING UPLOAD
+== Swarming Download, Trickling Upload ==
 
 Because the shares being downloaded are distributed across a large number of
 nodes, the download process will pull from many of them at the same time. The
@@ -269,7 +281,7 @@ in the same facility, so the helper-to-storage-server bandwidth is huge.
 See "helper.txt" for details about the upload helper.
 
 
-THE FILESYSTEM LAYER
+== The Filesystem Layer ==
 
 The "filesystem" layer is responsible for mapping human-meaningful pathnames
 (directories and filenames) to pieces of data. The actual bytes inside these
@@ -299,7 +311,7 @@ links to spaces that are shared with specific other users, and other spaces
 that are globally visible.
 
 
-LEASES, REFRESHING, GARBAGE COLLECTION
+== Leases, Refreshing, Garbage Collection ==
 
 When a file or directory in the virtual filesystem is no longer referenced,
 the space that its shares occupied on each storage server can be freed,
@@ -320,7 +332,7 @@ See docs/garbage-collection.txt for further information, and how to configure
 garbage collection.
 
 
-FILE REPAIRER
+== File Repairer ==
 
 Shares may go away because the storage server hosting them has suffered a
 failure: either temporary downtime (affecting availability of the file), or a
@@ -377,7 +389,7 @@ to other nodes.
   in client behavior.
 
 
-SECURITY
+== Security ==
 
 The design goal for this project is that an attacker may be able to deny
 service (i.e. prevent you from recovering a file that was uploaded earlier)
@@ -441,7 +453,7 @@ normal web site, using username and password to give a user access to her
 capabilities).
 
 
-RELIABILITY
+== Reliability ==
 
 File encoding and peer-node selection parameters can be adjusted to achieve
 different goals. Each choice results in a number of properties; there are

diff --git a/docs/frontends/FTP-and-SFTP.txt b/docs/frontends/FTP-and-SFTP.txt
index 49b6eea7ed4732ef9ed61fcff6693e852e73d8cf..5e994bd8d2a7d996d8564550faecf2166012ecd4 100644 (file)
--- a/docs/frontends/FTP-and-SFTP.txt
+++ b/docs/frontends/FTP-and-SFTP.txt
@@ -1,4 +1,4 @@
-= Tahoe FTP/SFTP Frontend =
+= Tahoe FTP and SFTP Frontends =
 
 1.  FTP/SFTP Background
 2.  Tahoe Support
@@ -6,6 +6,8 @@
 4.  Configuring FTP Access
 5.  Configuring SFTP Access
 6.  Dependencies
+7.  Immutable and mutable files
+
 
 == FTP/SFTP Background ==
 
@@ -24,6 +26,7 @@ Both FTP and SFTP were developed assuming a UNIX-like server, with accounts
 and passwords, octal file modes (user/group/other, read/write/execute), and
 ctime/mtime timestamps.
 
+
 == Tahoe Support ==
 
 All Tahoe client nodes can run a frontend FTP server, allowing regular FTP
@@ -49,6 +52,7 @@ HTTP-based login mechanism, backed by simple PHP script and a database. The
 latter form is used by allmydata.com to provide secure access to customer
 rootcaps.
 
+
 == Creating an Account File ==
 
 To use the first form, create a file (probably in
@@ -72,6 +76,7 @@ either of these strings.
 Then add an 'accounts.file' directive to your tahoe.cfg file, as described
 in the next sections.
 
+
 == Configuring FTP Access ==
 
 To enable the FTP server with an accounts file, add the following lines to
@@ -96,6 +101,7 @@ that server in an "accounts.url" directive:
 You can provide both accounts.file and accounts.url, although it probably
 isn't very useful except for testing.
 
+
 == Configuring SFTP Access ==
 
 The Tahoe SFTP server requires a host keypair, just like the regular SSH