--- loncom/lonsql	2003/02/03 13:43:38	1.55
+++ loncom/lonsql	2003/07/25 17:07:06	1.56
@@ -3,7 +3,7 @@
 # The LearningOnline Network
 # lonsql - LON TCP-MySQL-Server Daemon for handling database requests.
 #
-# $Id: lonsql,v 1.55 2003/02/03 13:43:38 albertel Exp $
+# $Id: lonsql,v 1.56 2003/07/25 17:07:06 bowersj2 Exp $
 #
 # Copyright Michigan State University Board of Trustees
 #
@@ -39,9 +39,95 @@ lonsql - LON TCP-MySQL-Server Daemon for
 This script should be run as user=www.  
 Note that a lonsql.pid file contains the pid of the parent process.
 
-=head1 DESCRIPTION
+=head1 OVERVIEW
 
-lonsql is 
+The SQL database in LON-CAPA is used for catalog searches against
+resource metadata only. The authoritative version of the resource
+metadata is an XML-file on the normal file system (same file name as
+resource plus ".meta"). The SQL-database is a cache of these files,
+and can be reconstructed from the XML files at any time.
+
+The current database is implemented assuming a non-adjustable
+architecture involving these data fields (specific to each version of
+a resource).
+
+=over 4
+
+=item * title
+
+=item * author
+
+=item * subject
+
+=item * notes
+
+=item * abstract
+
+=item * mime
+
+=item * language
+
+=item * creationdate
+
+=item * lastrevisiondate
+
+=item * owner
+
+=item * copyright 
+
+=back 
+
+=head2 Purpose within LON-CAPA
+
+LON-CAPA is meant to distribute A LOT of educational content to A LOT
+of people. It is ineffective to directly rely on contents within the
+ext2 filesystem to be speedily scanned for on-the-fly searches of
+content descriptions. (Simply put, it takes a cumbersome amount of
+time to open, read, analyze, and close thousands of files.)
+
+The solution is to index various data fields that are descriptive of
+the educational resources on a LON-CAPA server machine in a
+database. Descriptive data fields are referred to as "metadata". The
+question then arises as to how this metadata is handled in terms of
+the rest of the LON-CAPA network without burdening client and daemon
+processes.
+
+The obvious solution, using lonc to send a query to a lond process,
+doesn't work so well in general as you can see in the following
+example:
+
+    lonc= loncapa client process    A-lonc= a lonc process on Server A
+    lond= loncapa daemon process
+
+                 database command
+    A-lonc  --------TCP/IP----------------> B-lond
+
+The problem emerges that A-lonc and B-lond are kept waiting for the
+MySQL server to "do its stuff", or in other words, perform the
+conceivably sophisticated, data-intensive, time-sucking database
+transaction.  By tying up a lonc and lond process, this significantly
+cripples the capabilities of LON-CAPA servers.
+
+The solution is to offload the work onto another process, and use
+lonc and lond just for requests and notifications of completed
+processing:
+
+                database command
+
+  A-lonc  ---------TCP/IP-----------------> B-lond =====> B-lonsql
+         <---------------------------------/                |
+           "ok, I'll get back to you..."                    |
+                                                            |
+                                                            /
+  A-lond  <-------------------------------  B-lonc   <======
+           "Guess what? I have the result!"
+
+Of course, depending on success or failure, the messages may vary, but
+the principle remains the same where a separate pool of children
+processes (lonsql's) handle the MySQL database manipulations.
+
+Thus, lonc and lond spend effectively no time waiting on results from
+the database.
 
 =head1 Internals