Minor fixes, especially in the beginning
[idzebra-moved-to-github.git] / doc / administration.xml
index b8c1f04..417a3da 100644 (file)
@@ -1,5 +1,5 @@
 <chapter id="administration">
- <!-- $Id: administration.xml,v 1.3 2002-04-09 13:26:26 adam Exp $ -->
+ <!-- $Id: administration.xml,v 1.5 2002-04-10 14:47:48 heikki Exp $ -->
  <title>Administrating Zebra</title>
  
  <para>
@@ -79,7 +79,7 @@
    Indexing is a per-record process, in which either insert/modify/delete
    will occur. Before a record is indexed search keys are extracted from
    whatever might be the layout the original record (sgml,html,text, etc..).
-   The Zebra system currently supports two fundamantal types of records:
+   The Zebra system currently supports two fundamental types of records:
    structured and simple text.
    To specify a particular extraction process, use either the
    command line option <literal>-t</literal> or specify a
@@ -99,7 +99,7 @@
   
   <para>
    You can edit the configuration file with a normal text editor.
-   parameter names and values are seperated by colons in the file. Lines
+   parameter names and values are separated by colons in the file. Lines
    starting with a hash sign (<literal>&num;</literal>) are
    treated as comments.
   </para>
   </para>
   
   <para>
+   FIXME - Didn't Adam make something to have multiple databases in multiple dirs...
+  </para>
+  
+  <para>
    <variablelist>
     
     <varlistentry>
      <listitem>
       <para>
        Specifies the Z39.50 database name.
+       FIXME - now we can have multiple databases in one server. -H
       </para>
      </listitem>
     </varlistentry>
   <title>Locating Records</title>
   
   <para>
-   The default behaviour of the Zebra system is to reference the
+   The default behavior of the Zebra system is to reference the
    records from their original location, i.e. where they were found when you
    ran <literal>zebraidx</literal>.
    That is, when a client wishes to retrieve a record
    disk space than simpler indexing methods, but it makes it easier for
    you to keep the index in sync with a frequently changing set of data.
    If you combine this system with the <emphasis>safe update</emphasis>
-   facility (see below), you never have to take your server offline for
+   facility (see below), you never have to take your server off-line for
    maintenance or register updating purposes.
   </para>
   
   </para>
   
   <para>
+   FIXME - There must be a simpler way to do this with Adams string tags -H
+  </para>
+
+  <para>
    For example, to update records of group <literal>esdd</literal>
    located below
    <literal>/data1/records/</literal> you should type:
   <title>Indexing with General Record IDs</title>
   
   <para>
-   When using this method you construct an (almost) arbritrary, internal
+   When using this method you construct an (almost) arbitrary, internal
    record key based on the contents of the record itself and other system
    information. If you have a group of records that explicitly associates
    an ID with each record, this method is convenient. For example, the
    each directory in the order specified and use the next specified
    directories as needed.
    The <emphasis>size</emphasis> is an integer followed by a qualifier
-   code, <literal>M</literal> for megabytes,
+   code, 
+   <literal>b</literal> for bytes,
    <literal>k</literal> for kilobytes.
+   <literal>M</literal> for megabytes,
+   <literal>G</literal> for gigabytes.
   </para>
   
   <para>
    For instance, if you have allocated two disks for your register, and
    the first disk is mounted
-   on <literal>/d1</literal> and has 200 Mb of free space and the
-   second, mounted on <literal>/d2</literal> has 300 Mb, you could
+   on <literal>/d1</literal> and has 2GB of free space and the
+   second, mounted on <literal>/d2</literal> has 3.6 GB, you could
    put this entry in your configuration file:
    
    <screen>
-    register: /d1:200M /d2:300M
+    register: /d1:2G /d2:3600M
    </screen>
    
   </para>
    your responsibility to ensure that enough space is available, and that
    other applications do not attempt to use the free space. In a large
    production system, it is recommended that you allocate one or more
-   filesystem exclusively to the Zebra register files.
+   file system exclusively to the Zebra register files.
   </para>
   
  </sect1>