X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fintroduction.xml;h=3ef6a0bf10baf07aa467aad10e979f7df61d797e;hb=58b2fdadbb7b8a8845ff67501520fe1660dedeee;hp=4ddb58ffd1def73697c49289c58abd2c0dd441f8;hpb=ab0fd2f75e554d1c9c0e722abf073f9840f7739b;p=yaz-moved-to-github.git

diff --git a/doc/introduction.xml b/doc/introduction.xml
index 4ddb58f..3ef6a0b 100644
--- a/doc/introduction.xml
+++ b/doc/introduction.xml
@@ -1,4 +1,4 @@
-<!-- $Id: introduction.xml,v 1.5 2001-10-24 20:12:36 adam Exp $ -->
+<!-- $Id: introduction.xml,v 1.8 2002-08-17 07:55:51 adam Exp $ -->
  <chapter id="introduction"><title>Introduction</title>
   
   <para>
@@ -13,18 +13,19 @@
    It is, by far, the easiest way to develop clients in C.
    Server implementers should consider the 
    <link linkend="server">generic frontend server</link>.
-   None of those high-level API's support the whole protocol, but
-   they support most facilities used in existing Z39.50
+   None of those high-level APIs support the whole protocol, but
+   they do include most facilities used in existing Z39.50
    applications.
   </para>
   <para>
-   If you're developing non-standard extensions to Z39.50 or you're
+   If you're using 'exotic' functionality (meaning anything not included in
+   the high-level APIs), developing non-standard extensions to Z39.50 or you're
    going to develop an ILL application you'll have to learn the lower
-   level API's of &yaz;.
+   level APIs of &yaz;.
   </para>
   <para>
-   The basic low level modules, which is independent of the role,
-   consists of three primary interfaces:
+   The basic low level modules, which are independent of the role
+   (client or server), consist of three primary interfaces:
    
    <itemizedlist>
     <listitem><para>&asn;, which provides a C representation of the Z39.50
@@ -47,7 +48,7 @@
    provided by the &odr; (Open Data Representation) subsystem.
   </para>
   <para>
-   &odr; is a basic mechanism for representing an
+    &odr; is a basic mechanism for representing an
    ASN.1 type in the C programming language, and for implementing BER
    encoders and decoders for values of that type. The types defined in
    the &asn; module generally have the prefix <literal>Z_</literal>, and
@@ -55,16 +56,21 @@
    specification of the protocol (generally Z39.50-1995). In the case of
    base types (those originating in the ASN.1 standard itself), the prefix
    <literal>Odr_</literal> is sometimes seen. Either way, look for
-   the actual definition in either <filename>proto.h</filename> (for the types
+   the actual definition in either <filename>z-core.h</filename> (for the types
    from the protocol), <filename>odr.h</filename> (for the primitive ASN.1
-   types, or <filename>odr_use.h</filename> (for the ASN.1
-   <emphasis>useful</emphasis> types). The &asn; library also
-   provides functions (which are, in turn, defined using &odr;
-   primitives) for encoding and decoding data values. Their general form is
+   types).
+   The &asn; library also provides functions (which are, in turn,
+   defined using &odr; primitives) for encoding and decoding data values.
+   Their general form is
 
-   <synopsis>
-    int z_xxx(ODR o, Z_xxx **p, int optional, const char *name);
-   </synopsis>
+   <funcsynopsis>
+    <funcprototype><funcdef>int <function>z_<replaceable>xxx</replaceable></function></funcdef>
+     <paramdef>ODR <parameter>o</parameter></paramdef>
+     <paramdef>Z_<replaceable>xxx</replaceable> **<parameter>p</parameter></paramdef>
+     <paramdef>int <parameter>optional</parameter></paramdef>
+     <paramdef>const char *<parameter>name</parameter></paramdef>
+    </funcprototype>
+   </funcsynopsis>
    (note the lower-case &quot;z&quot; in the function name)
   </para>
 
@@ -84,7 +90,7 @@
    (passively or actively, depending on the role of your application),
    and for exchanging BER-encoded PDUs over that connection. When you
    create a connection endpoint, you need to specify what transport to
-   use (TCP/IP or SSL).
+   use (TCP/IP, SSL or UNIX sockets).
    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.
@@ -103,8 +109,8 @@
    can use SNACC or BERUtils instead, and still have the benefits of the
    transparent transport approach of the &comstack; module. Secondly,
    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;.
+   event-processing structure, in a way that is incompatible with
+   the &comstack; interface or some other part of &yaz;.
   </para>
  </chapter>
 
@@ -118,7 +124,7 @@
  sgml-indent-step:1
  sgml-indent-data:t
  sgml-parent-document:"yaz.xml"
- sgml-local-catalogs: "../../docbook/docbook.cat"
+ sgml-local-catalogs: nil
  sgml-namecase-general:t
  End:
  -->