Update docs to reflect username chars change
[blerg.git] / www / doc / index.html
index 9a85061..9b2e3df 100644 (file)
@@ -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
 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
 
 <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>
 
 
 <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
 <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
 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>
 
 <table class="statistics">
 <tr><td>maximum record size</td><td>65535 bytes</td></tr>