-<!-- $Id: asn.xml,v 1.6 2001-08-08 19:33:21 adam Exp $ -->
+<!-- $Id: asn.xml,v 1.7 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title>The ASN Module</title>
<sect1><title>Introduction</title>
<para>
<para>
As well as the individual PDU functions, a function
<function>zget_APDU()</function> is provided, which allocates
- a toplevel Z-APDU of the type requested:
+ a top-level Z-APDU of the type requested:
</para>
<synopsis>
-<!-- $Id: client.xml,v 1.1 2001-08-08 19:33:21 adam Exp $ -->
+<!-- $Id: client.xml,v 1.2 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title>The YAZ client</title>
<sect1><title>Introduction</title>
<para>
- yaz-client is a linemode Z39.50 client. It supports a fair amount
+ yaz-client is a line-mode Z39.50 client. It supports a fair amount
of the functionality of the Z39.50-1995 standard, but some things you
- need to enable or disable by recompilation.
+ need to enable or disable by re-compilation.
Its primary purpose is to exercise the
package, and verify that the protocol works OK.
For the same reason some commands offers more functionality than others.
- Commands that exercies common Z39.50 services such as search and present
+ Commands that exercises common Z39.50 services such as search and present
have more features than less common supported services, such as Extended
Services (ItemOrder, ItemUpdate,..).
</para>
<literal>-v</literal> <replaceable>level</replaceable>
</term><listitem>
<simpara>Sets the LOG level to <replaceable>level</replaceable>.
- Level is a sequence of tokens separated by comman. Each token
+ Level is a sequence of tokens separated by comma. Each token
is a integer or a named LOG item - one of
<literal>fatal</literal>,
<literal>debug</literal>,
</term>
<listitem>
<para>Sends an Item Order Request using the ILL External.
- <replaceable>type</replaceable> is either 1 or 2 which correponds to
+ <replaceable>type</replaceable> is either 1 or 2 which corresponds to
ILL-Profile 1 and 2 respectively. The <replaceable>no</replaceable>
is the Result Set position of the record to be ordered.
</para>
<screen>
f @attrset Bib-1 @and @attr GILS 1=2008 Washington @attr 1=21 weather
</screen>
- For the full specifiction of the Prefix Query see the section
+ For the full specification of the Prefix Query see the section
<link linkend="PQF">Prefix Query Format</link>.
</para>
</sect1>
-<!-- $Id: comstack.xml,v 1.2 2001-07-19 23:29:40 adam Exp $ -->
+<!-- $Id: comstack.xml,v 1.3 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title id="comstack">The COMSTACK Module</title>
<sect1><title>Synopsis (blocking mode)</title>
<para>
Closes the connection (as elegantly as the lower layers will permit),
- and releases the resouces pointed to by the
+ and releases the resources pointed to by the
<literal>handle</literal>
parameter. The
<literal>handle</literal>
The <function>cs_get()</function> function will sometimes
(notably in the TCP/IP mode) read more than a single protocol package
off the network. When this happens, the extra package is stored
- by the subsystem. After callig <function>cs_get()</function>, and before
+ by the subsystem. After calling <function>cs_get()</function>, and before
waiting for more input, You should always call
<function>cs_more()</function>
to check if there's a full protocol package already read. If
<para>
Complete a connect operation initiated by <function>cs_connect()</function>.
It will return 0 on success; 1 if the operation has not yet completed (in
- this case, call the function again later); -1 if an error has occured.
+ this case, call the function again later); -1 if an error has occurred.
</para>
</sect1>
</synopsis>
<para>
- This finalises the server-side association establishment, after
+ This finalizes the server-side association establishment, after
cs_listen has completed successfully. It returns a new connection
endpoint, which represents the new association. The application will
typically wish to fork off a process to handle the association at this
</synopsis>
<para>
- on an established connection to retrieve the hostname of the remote host.
+ on an established connection to retrieve the host-name of the remote host.
</para>
<note>
<sect2><title>Installing Xtimosi</title>
<para>
- Although you will have to download Peter Furniss' XTI/mOSI
+ Although you will have to down-load Peter Furniss' XTI/mOSI
implementation for yourself, we've tried to make the integration as
simple as possible.
</para>
</screen>
<para>
- When you have downloaded and unpacked the archive, it will (we assume)
+ When you have down-loaded and unpacked the archive, it will (we assume)
have created a directory called <literal>xtimosi</literal>.
We suggest that you place this directory <emphasis>in the same
directory</emphasis> where you unpacked the &yaz;
-<!-- $Id: frontend.xml,v 1.4 2001-07-20 21:34:36 adam Exp $ -->
+<!-- $Id: frontend.xml,v 1.5 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title id="server">Making an IR Server for Your Database</title>
<sect1><title>Introduction</title>
<para>
If you aren't into documentation, a good way to learn how the
- backend interface works is to look at the <filename>backend.h</filename>
+ back end interface works is to look at the <filename>backend.h</filename>
file. Then, look at the small dummy-server in
<filename>ztest/ztest.c</filename>. Finally, you can have a look at
the <filename>seshigh.c</filename> file, which is where most of the
<para>
The backend interface was designed in anticipation of a specific
integration task, while still attempting to achieve some degree of
- generality. We realise fully that there are points where the
+ generality. We realize fully that there are points where the
interface can be improved significantly. If you have specific
functions or parameters that you think could be useful, send us a
mail (or better, sign on to the mailing list referred to in the
- toplevel README file). We will try to fit good suggestions into future
+ top-level README file). We will try to fit good suggestions into future
releases, to the extent that it can be done without requiring
too many structural changes in existing applications.
</para>
will include other files from the <filename>include/yaz</filename>
directory, so you'll probably want to use the -I option of your
compiler to tell it where to find the files. When you run
- <literal>make</literal> in the toplevel &yaz; directory,
+ <literal>make</literal> in the top-level &yaz; directory,
everything you need to create your server is put the
<filename>lib/libyaz.a</filename> library.
</para>
<varlistentry><term>
<literal>void (*bend_stop)(struct statserv_options_block *p)</literal>
</term>
- <listitem><para>Pointer to function which is called whenver the server
+ <listitem><para>Pointer to function which is called whenever the server
has stopped listening for incoming connections. This function pointer
has a default value of NULL in which case it isn't called.
When the server operates as an NT service this handler is called
<sect2><title>Search and retrieve</title>
<para>We now describe the handlers that are required to support search -
- and retrieve. You must support two functions - one for seearch - and one
+ and retrieve. You must support two functions - one for search - and one
for fetch (retrieval of one record). If desirable you can provide a
third handler which is called when a present request is received which
allows you to optimize retrieval of multiple-records.
<sect2><title>Delete</title>
<para>
- For backends that supports delete of a result set only one handler
+ For back-ends that supports delete of a result set only one handler
must be defined.
</para>
-<!-- $Id: future.xml,v 1.2 2001-07-19 23:29:40 adam Exp $ -->
+<!-- $Id: future.xml,v 1.3 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title>Future Directions</title>
<para>
- We have a new and better version of the frontend server on the drawing
+ We have a new and better version of the front-end server on the drawing
board. Resources and external commitments will govern when we'll be
- able to do something real with it. Fetures should include greater
- flexibility, greter support for access/resource control, and easy
+ able to do something real with it. Features should include greater
+ flexibility, greater support for access/resource control, and easy
support for Explain (possibly with Zebra as an extra database engine).
</para>
-<!-- $Id: indexdata.xml,v 1.3 2001-07-20 21:34:36 adam Exp $ -->
+<!-- $Id: indexdata.xml,v 1.4 2001-08-13 09:42:54 adam Exp $ -->
<appendix><title>About Index Data</title>
<para>
Index Data is a consulting and software-development enterprise that
- specialises in library and information management systems. Our
+ specializes in library and information management systems. Our
interests and expertise span a broad range of related fields, and one
of our primary, long-term objectives is the development of a powerful
information management
- system with open network interfaces and hypermedia capabilities.
+ system with open network interfaces and hyper-media capabilities.
</para><para>
We make this software available free of charge, on a fairly unrestrictive
license; as a service to the networking community, and to further the
-<!-- $Id: introduction.xml,v 1.2 2001-07-19 23:29:40 adam Exp $ -->
+<!-- $Id: introduction.xml,v 1.3 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title>Introduction</title>
<para>
and for exchanging BER-encoded PDUs over that connection. When you
create a connection endpoint, you need to specify what transport to
use (OSI or TCP/IP), and which protocol you want to use (SR or
- Z39.50). For the remainer of the connection's lifetime, you don't have
+ Z39.50). For the remainder of the connection's lifetime, you don't have
to worry about the underlying transport protocol at all - the &comstack;
will ensure that the correct mechanism is used.
</para>
if you don't like the protocol API provided by &odr;/&asn;, you
can use SNACC or BERUtils instead, and still have the benefits of the
transparent transport approach of the &comstack; module. Secondly,
- we realise that you may have to fit the toolkit into an existing
+ we realize that you may have to fit the toolkit into an existing
event-processing structure, in a way that
is incompatible with the &comstack; interface or some other part of &yaz;.
</para>
-<!-- $Id: odr.xml,v 1.3 2001-07-20 21:34:36 adam Exp $ -->
+<!-- $Id: odr.xml,v 1.4 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title id="odr">The ODR Module</title>
<sect1><title>Introduction</title>
small bits of space, the system maintains a freelist of larger chunks
of memory, which are handed out in small bits. This scheme is
generally known as a <emphasis>nibble memory</emphasis> system.
- It is very useful for maintaing short-lived constructions such
+ It is very useful for maintaining short-lived constructions such
as protocol PDUs.
</para>
The integer pointed to by len is set to the length of the encoded
data, and a pointer to that data is returned. <literal>*size</literal>
is set to the size of the buffer (unless <literal>size</literal> is null,
- signalling that you are not interested in the size). The next call to
+ signaling that you are not interested in the size). The next call to
a primitive function using the same &odr; stream will overwrite the
data, unless a different buffer has been supplied using the call
</para>
</para>
<para>
- It is important to realise that the ODR stream will not release this
+ It is important to realize that the ODR stream will not release this
memory when you call <function>odr_reset()</function>: It will
merely update its internal pointers to prepare for the encoding of a
new data value.
be released <emphasis>only</emphasis> if the <literal>can_grow</literal>
parameter to <function>odr_setbuf()</function> was nonzero. The
<literal>can_grow</literal> parameter, in other words, is a way of
- signalling who is to own the buffer, you or the ODR stream. If you never call
+ signaling who is to own the buffer, you or the ODR stream. If you never call
<function>odr_setbuf()</function> on your encoding stream, which is
typically the case, the buffer allocated by the stream will belong to
the stream by default.
type has a dual function. Depending on the settings of the ODR
stream which is supplied as a parameter, the function may be used
either to encode or decode data. The functions that can be built
- using these primitive functions, to represent more complex datatypes, share
+ using these primitive functions, to represent more complex data types, share
this quality. The result is that you only have to enter the definition
for a type once - and you have the functionality of encoding, decoding
(and pretty-printing) all in one unit. The resulting C source code is
In many cases, the model of the XDR functions works quite well in this
role.
In others, it is less elegant. Most of the hassle comes from the optional
- SEQUENCE memebers which don't exist in XDR.
+ SEQUENCE members which don't exist in XDR.
</para>
<sect2><title>The Primitive ASN.1 Types</title>
</synopsis>
<para>
- The C OID represenation is simply an array of integers, terminated by
+ The C OID representation is simply an array of integers, terminated by
the value -1 (the <literal>Odr_oid</literal> type is synonymous with
the <literal>int</literal> type).
We suggest that you use the OID database module (see section
You could, of course, name your structures, types, and functions any way
you please - as long as you're consistent, and your code is easily readable.
<literal>odr_ok</literal> is just that - a predicate that returns the
- state of the stream. It is used to ensure that the behaviour of the new
+ state of the stream. It is used to ensure that the behavior of the new
type is compatible with the interface of the primitive types.
</para>
Notice that the interface here gets kind of nasty. The reason is
simple: Explicitly tagged, constructed types are fairly rare in
the protocols that we care about, so the
- aesthetic annoyance (not to mention the dangers of a cluttered
+ esthetic annoyance (not to mention the dangers of a cluttered
interface) is less than the time that would be required to develop a
better interface. Nevertheless, it is far from satisfying, and it's a
point that will be worked on in the future. One option for you would
<sect2><title>SEQUENCE OF</title>
<para>
- To handle sequences (arrays) of a apecific type, the function
+ To handle sequences (arrays) of a specific type, the function
</para>
<synopsis>
</para>
<para>
- The ASN.1 specifictions naturally requires that each member of a
+ The ASN.1 specifications naturally requires that each member of a
CHOICE have a distinct tag, so they can be told apart on decoding.
Sometimes it can be useful to define a CHOICE that has multiple types
that share the same tag. You'll need some other mechanism, perhaps
-<!-- $Id: tools.xml,v 1.4 2001-08-08 19:33:21 adam Exp $ -->
+<!-- $Id: tools.xml,v 1.5 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title>Supporting Tools</title>
<para>
In support of the service API - primarily the ASN module, which
- provides the programmatic interface to the Z39.50 APDUs, &yaz; contains
+ provides the pro-grammatic interface to the Z39.50 APDUs, &yaz; contains
a collection of tools that support the development of applications.
</para>
index, such as title (ti) and author indexes (au). The CCL standard
itself doesn't specify a particular set of qualifiers, but it does
suggest a few short-hand notations. You can customize the CCL parser
- to support a particular set of qualifiers to relect the current target
+ to support a particular set of qualifiers to reflect the current target
profile. Traditionally, a qualifier would map to a particular
use-attribute within the BIB-1 attribute set. However, you could also
define qualifiers that would set, for example, the
<para>
which takes the CCL profile (<literal>bibset</literal>) and query
(<literal>str</literal>) as input. Upon successful completion the RPN
- tree is returned. If an error eccur, such as a syntax error, the integer
+ tree is returned. If an error occur, such as a syntax error, the integer
pointed to by <literal>error</literal> holds the error code and
<literal>pos</literal> holds the offset inside query string in which
the parsing failed.
</para>
<para>
- An english representation of the error may be obtained by calling
+ An English representation of the error may be obtained by calling
the <literal>ccl_err_msg</literal> function. The error codes are
listed in <filename>ccl.h</filename>.
</para>
<note>
<para>
- The nibble memory pool is shared amonst threads. POSIX
+ The nibble memory pool is shared amongst threads. POSIX
mutex'es and WIN32 Critical sections are introduced to keep the
module thread safe. On WIN32 function <function>nmem_init()</function>
- initialises the Critical Section handle and should be called once
+ initializes the Critical Section handle and should be called once
before any other nmem function is used.
</para>
</note>
projects / yaz-moved-to-github.git / commitdiff