Rolling commit. There's a little more prose in the developing
[idzebra-moved-to-github.git] / doc / administration.xml
index 417a3da..1c8df0e 100644 (file)
@@ -1,7 +1,13 @@
 <chapter id="administration">
- <!-- $Id: administration.xml,v 1.5 2002-04-10 14:47:48 heikki Exp $ -->
+ <!-- $Id: administration.xml,v 1.9 2002-10-17 08:10:08 mike Exp $ -->
  <title>Administrating Zebra</title>
+ <!-- ### It's a bit daft that this chapter (which describes half of
+          the configuration-file formats) is separated from
+          "recordmodel.xml" (which describes the other half) by the
+          instructions on running zebraidx and zebrasrv.  Some careful
+          re-ordering is required here.
+ -->
+
  <para>
   Unlike many simpler retrieval systems, Zebra supports safe, incremental
   updates to an existing index.
    explained further in the following sections.
   </para>
   
-  <para>
+  <!--
    FIXME - Didn't Adam make something to have multiple databases in multiple dirs...
-  </para>
+  -->
   
   <para>
    <variablelist>
      <listitem>
       <para>
        Specifies the Z39.50 database name.
-       FIXME - now we can have multiple databases in one server. -H
+       <!-- FIXME - now we can have multiple databases in one server. -H -->
       </para>
      </listitem>
     </varlistentry>
        group of records. If you plan to update/delete this type of
        records later this should be specified as 1; otherwise it
        should be 0 (default), to save register space.
+       <!-- ### this is the first mention of "register" -->
        See <xref linkend="file-ids"/>.
       </para>
      </listitem>
      </listitem>
     </varlistentry>
     <varlistentry>
+     <!-- ### probably a better place to define "register" -->
      <term>register: <replaceable>register-location</replaceable></term>
      <listitem>
       <para>
      <term>keyTmpDir: <replaceable>directory</replaceable></term>
      <listitem>
       <para>
-       Directory in which temporary files used during zebraidx' update
+       Directory in which temporary files used during zebraidx's update
        phase are stored. 
       </para>
      </listitem>
    That is, when a client wishes to retrieve a record
    following a search operation, the files are accessed from the place
    where you originally put them - if you remove the files (without
-   running <literal>zebraidx</literal> again, the client
-   will receive a diagnostic message.
+   running <literal>zebraidx</literal> again, the server will return
+   diagnostic number 14 (``System error in presenting records'') to
+   the client.
   </para>
   
   <para>
    in the configuration file. In addition, you should set
    <literal>storeKeys</literal> to <literal>1</literal>, since the Zebra
    indexer must save additional information about the contents of each record
-   in order to modify the indices correctly at a later time.
+   in order to modify the indexes correctly at a later time.
   </para>
   
-  <para>
-   FIXME - There must be a simpler way to do this with Adams string tags -H
-  </para>
+   <!--
+    FIXME - There must be a simpler way to do this with Adams string tags -H
+     -->
 
   <para>
    For example, to update records of group <literal>esdd</literal>
     In order to make changes to the system take effect for the
     users, you'll have to submit a "commit" command after a
     (sequence of) update operation(s).
-    You can ask the indexer to commit the changes immediately
-    after the update operation:
    </para>
    
    <para>
     
     <screen>
-     $ zebraidx update /d1/records update /d2/more-records commit
+     $ zebraidx update /d1/records 
+     $ zebraidx commit
     </screen>
     
    </para>
    <para>
     
     <screen>
-     $ zebraidx -g books update /d1/records update /d2/more-records
+     $ zebraidx -g books update /d1/records  /d2/more-records
      $ zebraidx -g fun update /d3/fun-records
      $ zebraidx commit
     </screen>