Monster changes en route to 1.17. Esp. with new documentation.

1 files changed, 4 insertions, 129 deletions

diff --git a/README b/README
index 077b6c4..fd1cdc7 100644
--- a/README
+++ b/README
@@ -1,130 +1,5 @@
-$Id: README,v 1.6 2002/05/14 21:47:15 helios Exp $
-
-
-Homepage
---------
-http://www.grubbybaby.com/mod_log_sql/
-
-
-Approach
---------
-This project was formerly known as mod_log_mysql. It has been renamed
-to mod_log_sql in order to reflect the project goal of
-database-inspecificity. The module currently supports MySQL, and
-development for other database backends is underway.
-
-In order to save speed and overhead, links are kept alive in between
-queries.  This module uses one SQL link per httpd process.  Among other
-things, this means that this module supports logging into only one
-MySQL server, and for now, also, only one SQL database.  But that's a
-small tradeoff compared to the blinding speed of this module.
-
-Virtual hosts are supported in the same manner they are in the regular
-logging modules.  You define some basic 'global' directives in the 
-main server config, then you define more specific 'local' directives
-inside each virtualhost stanza.  
-
-SQL links are opened by each child process when it is born.  Error reporting
-is robust throughout and will let you know about database issues
-in the standard Apache error-log for the server or virtual server. 
-
-A robust "preserve" capability has now been implemented.  This permits
-the module to preserve any failed INSERT commands to a local file on
-its machine.  In any situation that the database is unavailable -- e.g.
-the network fails, you reboot the db host, etc. -- mod_log_sql will
-note this in the error log and begin appending its log entries to the
-preserve file (which is created with the user & group ID of the running
-Apache process, e.g. "nobody" on many Linux installations).  At the time
-that your MySQL server returns to service, each of these preserve files
-is easily imported because it is simply a series of SQL insert statements:
-
-  # mysql -uadminuser -p mydbname < /tmp/mysql-preserve
-
-
-
-Supported directives
---------------------
-
-Please see the web-based documentation for full explanation of all
-supported run-time directives.
-
- http://www.grubbybaby.com/mod_log_sql/directives.html
-
-See the FAQ for some handy examples:
-
- http://www.grubbybaby.com/mod_log_sql/faq.html
-
-
-What gets logged by default?
-----------------------------
-
-All the data that would be contained in the "Combined Log Format" 
-is logged by default, plus a little extra.  Your best bet is to
-begin by accepting this default, then later customize the log
-configuration based on your needs.
-
-The online documentation of the run-time directives includes a full
-explanation of what you can log, including examples.
-  
-  
-Notes
------
-
-* You will customarily set most of your run-time configuration directives
-  on a per-virtualserver basis, with only MySQLMassVirtualHosting,
-  MySQLLoginInfo, MySQLDatabase, MySQLSocketFile, MySQLCreateTables,
-  and MySQLMassVirtualHosting 'outside' in the main server config.  Any
-  directives other than those in the main config do NOT get inherited
-  by the virutal servers.
-
-* The 'time_stamp' field is stored in an UNSIGNED INTEGER column, in the
-  standard unix "seconds since 1/1/1970 12:00:00" format.  This is
-  superior to storing the access time as a string due to size
-  requirements: an UNSIGNED INT type fits in 4 bytes, whereas the Apache date
-  string (e.g. "18/Nov/2001:13:59:52 -0800") requires 26 bytes --
-  significantly larger, and those extra 22 bytes will add up over the
-  thousands of accesses that a busy server will experience.  Besides,
-  an INT type is far more flexible for comparisons, etc.
-
-  In MySQL 3.21 and above you can easily convert this to a human
-  readable format using from_unixtime(), e.g.:
-
-  select remote_host,request_uri,from_unixtime(time_stamp) from access_log;
-
-  The enclosed perl program make_combined_log.pl shows how you can
-  extract your access records in a format that is completely Combined
-  Log Format compliant.  You can then feed this to your favorite web
-  log analysis tool.
-
-* The table's string values can be CHAR or VARCHAR, at a length of your choice.
-  VARCHAR is superior because it truncates long strings; CHAR types are
-  fixed-length and will be padded with spaces.  Just like the
-  time_stamp described above, that kind of space waste will add up over
-  thousands of records.
-
-* Be careful not to go overboard setting fields to NOT NULL.  If a field is
-  marked NOT NULL then it must contain data in the INSERT or the INSERT
-  will fail.  
-
-* Apache normally logs numeric fields with a '-' character to mean "not
-  applicable," e.g. bytes_sent on a request with a 304 response code. 
-  Since '-' is an illegal character in an SQL numeric field, such
-  fields are assigned the value 0 instead of '-' which, of course,
-  makes perfect sense anyway.
-
-
-
-Author / Maintainer
--------------------
-
-The actual logging code was taken from the already existing flat file
-text modules, so all that credit goes to the Apache Server group.  
-
-The MySQL routines and directives were added by Zeev Suraski
-<bourbon@netvision.net.il>.
-
-All changes from 1.06+ and the new documentation were added by 
-Chris Powell <chris@grubbybaby.com>.  It seems that the module had fallen
-into the "unmaintained" category -- it hadn't been updated since 1998 --
-so Chris adopted it as the new maintainer.
+$Id: README,v 1.7 2002/11/14 03:51:34 helios Exp $
 
+This document has been superseded by the new documentation
+in the Documentation/ directory.  There you will find
+PS, plaintext, and HTML versions of the documentation.