--- loncom/html/adm/help/searchcat.html	2001/08/28 12:13:52	1.1
+++ loncom/html/adm/help/searchcat.html	2005/04/07 06:56:22	1.3
@@ -158,7 +158,7 @@ Browsing and searching should only be
  
 * either user specific (georgio can only browse and search
    /res/DOMAIN/georgio)
-* or has advanced status as indicated by $ENV{'user.adv'}
+* or has advanced status as indicated by $env{'user.adv'}
 </pre> 
 </li>
 <li>
@@ -186,6 +186,64 @@ the specific resource.  Advanced users c
 <h3>6. Notes on software architecture</h3>
 <br clear='all' />
 <p>
+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.)
+</p>
+<p>
+The solution is to hash-index various data fields that are
+descriptive of the educational resources on a LON-CAPA server
+machine.  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.  I now
+answer this question in the format of Problem and Solution
+below.
+</p>
+<p>
+<pre>
+PROBLEM SITUATION:
+
+  If Server A wants data from Server B, Server A uses a lonc process to
+  send a database command to a Server B lond process.
+    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. 
+
+  While commercial databases have a variety of features that ATTEMPT to
+  deal with this, freeware databases are still experimenting and exploring
+  with different schemes with varying degrees of performance stability.
+
+THE SOLUTION:
+
+  A separate daemon process was created that B-lond works with to
+  handle database requests.  This daemon process is called "lonsql".
+
+  So,
+                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.
+</pre>
 </p>
 <br />&nbsp;<br />
 <a name='limitations' />