Update docs to reflect username chars change

diff --git a/www/doc/index.html b/www/doc/index.html
index 9a85061..9b2e3df 100644 (file)
--- a/www/doc/index.html
+++ b/www/doc/index.html
@@ -172,14 +172,13 @@ For the HTTP backend, you'll get nothing (since it will have crashed),
 or maybe a 502 Bad Gateway if you have it behind another web server.
 
 <p>All usernames must be 32 characters or less.  Usernames must contain
-only the ASCII characters 0-9, A-Z, a-z, underscore (_), period (.),
-hyphen (-), single quote ('), and space ( ).  Passwords can be at most
-64 bytes, and have no limits on characters (but beware: if you have a
-null in the middle, it will stop checking there because I use
-<code>strncmp(3)</code> to compare).
+only the ASCII characters 0-9, A-Z, a-z, underscore (_), and hyphen (-).
+Passwords can be at most 64 bytes, and have no limits on characters (but
+beware: if you have a null in the middle, it will stop checking there
+because I use <code>strncmp(3)</code> to compare).
 
 <p>Tags must be 64 characters or less, and can contain only the ASCII
-characters 0-9, A-Z, a-z, hyphen (-), and underscore (_).
+characters 0-9, A-Z, a-z, underscore (_), and hyphen (-).
 
 <h3><a name="api_create">/create</a> - create a new user</a></h3>
 
@@ -362,14 +361,13 @@ until after I wrote Blërg. :)
 <p>I was impressed by <a
 href="http://www.varnish-cache.org/">varnish</a>'s design, so I decided
 early in the design process that I'd try out mmaped I/O.  Each user in
-Blërg has their own database, which consists of one or more data and
-index files, and a metadata file.  When a database is opened, only the
-metadata is actually read (currently a single 64-bit integer keeping
-track of the last record id).  The data and index files are memory
+Blërg has their own database, which consists of a metdata file, and one
+or more data and index files.  The data and index files are memory
 mapped, which hopefully makes things more efficient by letting the OS
-handle when to read from disk.  The index files are preallocated because
-I believe it's more efficient than writing to it 40 bytes at a time as
-records are added.  The database's limits are reasonable:
+handle when to read from disk (or maybe not &mdash I haven't benchmarked
+it).  The index files are preallocated because I believe it's more
+efficient than writing to it 40 bytes at a time as records are added.
+The database's limits are reasonable:
 
 <table class="statistics">
 <tr><td>maximum record size</td><td>65535 bytes</td></tr>