X-Git-Url: http://git.indexdata.com/?p=yaz-moved-to-github.git;a=blobdiff_plain;f=doc%2Fintroduction.xml;h=f531c749cab6f4dbce4a087b8602d4254f52b3fa;hp=785bc82a21c408e8dc53d0f91e77f8dbcc8e9706;hb=bd7e251dac1b07c54884d26295f66b90cfb23131;hpb=ce853cc4919ab346fd629e7727905d3ee6e1129f

diff --git a/doc/introduction.xml b/doc/introduction.xml
index 785bc82..f531c74 100644
--- a/doc/introduction.xml
+++ b/doc/introduction.xml
@@ -1,17 +1,34 @@
-<!-- $Id: introduction.xml,v 1.2 2001-07-19 23:29:40 adam Exp $ -->
- <chapter><title>Introduction</title>
+<!-- $Id: introduction.xml,v 1.7 2001-10-26 20:13:44 adam Exp $ -->
+ <chapter id="introduction"><title>Introduction</title>
   
   <para>
-   The &yaz; toolkit offers several different levels of access to the
-   Z39.50 and SR protocols. The level that you need to use depends on
-   your requirements, and the role (server or client) that you
-   want to implement.
-  </para><para>
-   The basic level, which is independent of the role, consists of three
-   primary interfaces:
+   The <ulink url="http://www.indexdata.dk/yaz/">&yaz;</ulink>
+   toolkit offers several different levels of access to the
+   <ulink url="http://www.loc.gov/z3950/agency/">ISO23950/Z39.50</ulink>
+   and <ulink url="http://www.nlc-bnc.ca/iso/ill/">ILL</ulink> protocols.
+   The level that you need to use depends on your requirements, and
+   the role (server or client) that you want to implement.
+   If you're developing a client application you should consider the
+   <link linkend="zoom">ZOOM</link> API.
+   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 APIs support the whole protocol, but
+   they do include most facilities used in existing Z39.50
+   applications.
+  </para>
+  <para>
+   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 APIs of &yaz;.
+  </para>
+  <para>
+   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/SR
+    <listitem><para>&asn;, which provides a C representation of the Z39.50
       protocol packages (PDUs).
      </para></listitem>
     <listitem><para>&odr;, which encodes and decodes the packages according
@@ -23,7 +40,7 @@
    </itemizedlist>
    
    The &asn; module represents the ASN.1 definition of
-   the SR/Z39.50 protocol. It establishes a set of type and
+   the Z39.50 protocol. It establishes a set of type and
    structure definitions, with one structure for each of the top-level
    PDUs, and one structure or type for each of the contained ASN.1 types.
    For primitive types, or other types that are defined by the ASN.1
@@ -68,14 +85,14 @@
    (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 (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
+   use (TCP/IP or SSL).
+   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>
   <para>
    We call the combined interfaces to &odr;, &asn;, and &comstack; the service
-   level API. It's the API that most closely models the Z39.50/SR
+   level API. It's the API that most closely models the Z39.50
    service/protocol definition, and it provides unlimited access to all
    fields and facilities of the protocol definitions.
   </para>
@@ -86,7 +103,7 @@
    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>
@@ -102,7 +119,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:
  -->