<!doctype linuxdoc system>
<!--
- $Id: egate.sgml,v 1.6 1995/07/10 13:55:25 adam Exp $
+ $Id: egate.sgml,v 1.7 1995/07/20 08:14:47 adam Exp $
-->
<article>
<title>Email/Z39.50 gateway guide
<author>Europagate, 1995
-<date>$Revision: 1.6 $
+<date>$Revision: 1.7 $
<abstract>
This document describes a Email server that provides access to the
Z39.50 protocol.
serves as an administrators guide, while the second part is a
follow-up on the Design deliverable (WP4.1) that outline the
deviations from the design. Also, the second part contains
-an overview of the source code.
+a quick overview of the source code.
<sect>Compilation
<p>
An ANSI C compiler is required in order to compile the ES software.
-The ES can use either CNIDR's zdist package or the YAZ package from
+The ES can use either CNIDR's Zdist package or the YAZ package from
Index Data to interface the Z39.50 protocol. So you need to obtain
-either of these first.
+one of these first.
The Zdist package can be found in:
$ patch <zdist.patch
</verb></tscreen>
+The ES server only depends on <tt>libz3950.a</tt> so you only need
+to build the Zdist software in the directory <tt/libz3950/.
+
YAZ can be found in:
<url url="ftp://ftp.algonet.se/pub/index/yaz/">.
The ES also use GNU's regex package to parse regular expressions.
The ES has been tested with regex-0.12. Some systems, such as Linux,
-comes with the regex package preinstalled.
+come with the regex package preinstalled.
Unpack <tt>egate.tar.gz</tt> and edit the top level <tt/Makefile/. Specify
where the GNU regex package is located and specify whether you use
-YAZ or zdist. One some systems, you may have to set the <tt/NETLIB/ as
+YAZ or Zdist. One some systems, you may have to set the <tt/NETLIB/ as
well.
-You may wish to set <tt/CC/ and <tt/CFLAGS/ in your shell, since these
-will affect the compilation — these are not set in the <tt/Makefile/.
+The shell variables <tt/CC/ and <tt/CFLAGS/ are used by the
+<tt/Makefile/ so you may modify these before compiling.
Now, type <tt/make/.
<sect>Installation
<p>
-If the compilation was successful, you should install the software.
+If the compilation succeeds, you should install the software.
Edit the <tt/Makefile/ and set the LIBDIR to the installation
directory. Since, the ES is executed by the mail system, and not by a
user, this directory shouldn't be globally executable.
<tt>es:"|/usr/local/lib/es/eti </tt><em>options</em><tt>"</tt>
-In this example the mail user name was <tt/es/ and the LIBDIR was
+In this example the mail user name is <tt/es/ and the LIBDIR is
<tt>/usr/local/lib/es</tt>.
The ES system can operate with or without the monitor. When using
implemented which maps a email username to a unique integer (email userid).
<item>The protocol persistency was implemented and more CCL commands
were added.
-<item>The MONITOR program was implemented.
+<item>The monitor program was implemented.
</enum>
The following sections cover the most important modules in the ES and
<p>
As described in the design, FIFOs are used to communicate between
-the ETI, MONITOR and KERNEL. The ES can run without the MONITOR,
-however. The primary reason for the presence of the MONITOR was
-to assure that the KERNELs would release the resources used by the
+the ETI, monitor and kernel. The ES can run without the monitor,
+however. The primary reason for the presence of the monitor was
+to assure that the kernel releases the resources used by the
persistency layer. But, since the persistency layer did turn out to
use virtually no disk space at all, there was no point in starting
-a KERNEL process to remove its files — hence this facility
-was not implemented. The only purpose of the MONITOR is to keep the
-number of running KERNELs at a maximum level and even that
-is probably useless since most unices will swap KERNEL processes
+a kernel process to remove its files — hence this facility
+was not implemented. The only purpose of the monitor is to keep the
+number of running kernels at a maximum level and even that
+is probably useless since most unices will swap kernel processes
out anyway.
The idle time
-before a KERNEL exits and saves its persistency file is not
-controlled by the MONITOR. Saving the persistency file and
+before a kernel exits and saves its persistency file is not
+controlled by the monitor. Saving the persistency file and
keeping it is usually a good approach — even when a
user doesn't reference/show old result-sets since the user
has a notion of <em/current target/ and database.
<tag>Database utility</tag> implemented in <tt>gw-db.[ch]</tt>. This
utility is used to map a user (email) to an integer.
<tag>String queue utility</tag> implemented in <tt>strqueue.[ch]</tt>. This
- utiltiy is used to queue incoming mail in the ETI, KERNEL and
- the MONITOR.
+ utiltiy is used to queue incoming mail in the ETI, kernel and
+ the monitor.
<tag>Pretty printer</tag> implemented in <tt>ttyemit.[ch]</tt>
— used by the URP.
<tag>FIFO IPC utiltiy</tag> implemented in <tt>gip*.[ch]</tt> —
- used by the ETI, KERNEL and MONITOR.
+ used by the ETI, kernel and monitor.
</descrip>
<tag/fml/ implements FML. The top level functions are implemented
of YAZ. This task is implemented in <tt>zaccess.c</tt>. The
public header file is called <tt>zaccess.h</tt>.
-<tag/kernel/ implements the ETI, KERNEL and MONITOR. The kernel
+<tag/kernel/ implements the ETI, kernel and monitor. The kernel
itself is implemented in <tt>main.c</tt>, <tt>urp.c</tt> and
<tt>persist.c</tt>. The ETI is implemented in <tt>eti.c</tt> and
- the MONITOR is implemented <tt>monitor.c</tt>.
+ the monitor is implemented <tt>monitor.c</tt>.
</descrip>
<sect>LICENSE