X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fintroduction.xml;h=cf194278140f90cf39ce4c21770a68d4214b7cec;hb=6f5c63a8b759040d31028a4f1437a9cbc7a21fd6;hp=aecfe6702708aba32dbf6e19c19112664dfc3a2c;hpb=add5a2db6b4360b1b448ad09f991a3977eb1220d;p=yaz-moved-to-github.git diff --git a/doc/introduction.xml b/doc/introduction.xml index aecfe67..cf19427 100644 --- a/doc/introduction.xml +++ b/doc/introduction.xml @@ -1,28 +1,24 @@ - + Introduction &yaz; is a C/C++ library for information retrieval applications - using the Z39.50/SRW protocols for information retrieval. + using the Z39.50/SRW/SRU protocols for information retrieval. Properties of &yaz;: - Fast operation. The C based BER encoders/decoders as well - as the server component of &yaz; is very fast. - - Complete Z39.50 - version 3 support. All newer extensions - including Z39.50-2000 have been incorporated. + version 3 support. Amendments and Z39.50-2002 revision is + supported. Supports - SRW - version 1.0 (over HTTP and HTTPS). + SRW/SRU + version 1.1 (over HTTP and HTTPS). Includes BER encoders/decoders for the @@ -59,6 +55,10 @@ on Windows using Microsoft Visual C++. + Fast operation. The C based BER encoders/decoders as well + as the server component of &yaz; is very fast. + + Liberal license that allows for commercial use of &yaz;. @@ -82,16 +82,16 @@ - + describes the ZOOM API of &yaz;. This is definitely worth a read if you wish to develop a Z39.50/SRW client. - + - describes the generic frontend server + describes the generic frontend server and explains how to develop server Z39.50/SRW applications for &yaz;. Obviously worth reading if you're to develop a server. @@ -126,7 +126,7 @@ contains sections for the various tools offered by &yaz;. Scan through the material quickly - and see what's relevant to you! SRW implementors + and see what's relevant to you! SRW/SRU implementors might find the CQL section particularly useful. @@ -136,10 +136,11 @@ goes through the details of the ODR module which is the work horse that encodes and decodes - BER packages. Implementors using ZOOM only do not need reading this. + BER packages. Implementors using ZOOM only, do not + need reading this. Most other Z39.50 implementors only need to read the first two - sections Introduction, - Using ODR. + sections ( and + ). @@ -161,12 +162,13 @@ toolkit offers several different levels of access to the ISO23950/Z39.50, ILL and - SRW protocols. + SRW + 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 ZOOM API. - It is, by far, the easiest way to develop clients in C. + It is, by far, the easiest way to develop clients in C. Server implementers should consider the generic frontend server. None of those high-level APIs support the whole protocol, but @@ -179,22 +181,52 @@ you're going to develop an ILL application you'll have to learn the lower level APIs of &yaz;. - - The basic low level modules, which are independent of the role - (client or server), consist of three primary interfaces: - + + The YAZ toolkit modules is shown in figure . + +
+ YAZ layers + + + + + + + + +
+ + There are four layers. - &asn;, which provides a C representation of the Z39.50 - protocol packages (PDUs). - - &odr;, which encodes and decodes the packages according - to the BER specification. - - &comstack;, which exchanges the encoded packages with - a peer process over a network. - + + A client or server application (or both). + This layer includes ZOOM and the generic frontend server. + + + + + The second layer provides a C represenation of the + protocol units (packages) for Z39.50 ASN.1, ILL ASN.1, + SRW SOAP. + + + + + The third layer encodes and decodes protocol data units to + simple packages (buffer with certain length). The &odr; module + encodes and decodes BER whereas the HTTP modules encodes and + decodes HTTP ruquests/responses. + + + + + The lowest layer is &comstack; which exchanges the encoded packages + with a peer process over a network. + + - + + The &asn; module represents the ASN.1 definition of the Z39.50 protocol. It establishes a set of type and structure definitions, with one structure for each of the top-level @@ -234,8 +266,8 @@ If you are using the premade definitions of the &asn; module, and you are not adding new protocol of your own, the only parts of &odr; that you - need to worry about are documented in section - Using ODR. + need to worry about are documented in + . @@ -248,7 +280,7 @@ create a connection endpoint, you need to specify what transport to 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; + to worry about the underlying transport protocol at all - the &comstack; will ensure that the correct mechanism is used. @@ -259,7 +291,7 @@ The reason that the &yaz; service-level API is a conglomerate of the - APIs from three different submodules is twofold. First, we wanted to allow + APIs from three different submodules is twofold. First, we wanted to allow the user a choice of different options for each major task. For instance, 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