X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Freference.xml;h=109eb2aaa4839bf227acadd6d2525001d7e40854;hb=cc9b18cf01e91da8c8902923916946d8668f7cbd;hp=644fe5877843eebf060155f2f24e465a294326c8;hpb=b65837a1f4aadf842d112f5e37382d93f26da83d;p=yazproxy-moved-to-github.git
diff --git a/doc/reference.xml b/doc/reference.xml
index 644fe58..109eb2a 100644
--- a/doc/reference.xml
+++ b/doc/reference.xml
@@ -3,7 +3,7 @@
Operating Environment
- The YAZ proxy is a single program. After startup it spawns
+ The YAZ proxy is a console program. After startup it spawns
a child process (except on Windows or if option -X is given).
The child process is the core of the proxy and it handles all
communication with clients and servers. The parent process
@@ -12,7 +12,7 @@
see .
- As an option the proxy may change user identity to a less privileged
+ As an option, the proxy may change user identity to a less privileged
user.
@@ -116,6 +116,81 @@
+
+
+ Query Caching
+
+ Simple stateless clients often send identical Z39.50 searches
+ in a relatively short period of time (e.g. in order to produce a
+ results-list page, the next page,
+ a single full-record, etc). And for many targets, it's
+ much more expensive to produce a new result set than to
+ reuse an existing one.
+
+
+ The proxy tries to solve that by remembering the last query for each
+ backend target, so that if an identical query is received next, it
+ is turned into Present Requests rather than new Search Requests.
+
+
+
+ In a future we release will will probably allows for
+ an arbitrary-sized cache for targets supporting named result sets.
+
+
+
+ You can enable/disable query caching using option -o.
+
+
+
+
+ Record Caching
+
+ As an option, the proxy may also cache result set records for the
+ last search.
+ The proxy takes into account the Record Syntax and CompSpec.
+ The CompSpec includes simple element set names as well.
+ By default the cache is 200000 bytes per session.
+
+
+
+
+ Query Validation
+
+ The Proxy may also be configured to trap particular attributes in
+ Type-1 queries and send Bib-1 diagnostics back to the client without
+ even consulting the backend target. This facility may be useful if
+ a target does not properly issue diagnostics when unsupported attributes
+ are send to it.
+
+
+
+
+ Record Syntax Validation
+
+ The proxy may be configured to accept, reject or convert records.
+ When accepted, the target passes search/present requests to the
+ backend target under the assumption that the target can honor the
+ request (In fact it may not do that). When a record is rejected because
+ the record syntax is "unsupported" the proxy returns a diagnostic to the
+ client. Finally, the proxy may convert records.
+
+
+ The proxy can convert from MARC to MARCXML and thereby offer an
+ XML version of any MARC record as long as it is ISO2709 encoded.
+ If the proxy is compiled with libXSLT support it can also
+ perform XSLT on XML.
+
+
+
+
+ Other Optimizations
+
+ We've had some plans to support global caching of result set records,
+ but this has not yet been implemented.
+
+
+
Proxy Configuration File
@@ -207,7 +282,7 @@
This can also be specified on the command line by using option
- -T. Refer to OPTIONS.
+ -T. Refer to OPTIONS in .
@@ -220,7 +295,7 @@
This can also be specified on the command line by using option
- -i. Refer to OPTIONS.
+ -i. Refer to OPTIONS in .
@@ -331,7 +406,7 @@
A target that supports use attributes 1,4, 1000 through 1003 and
no other use attributes, could use the following rules:
- <attribute type="1" value="1,4,1000-1003">
+ <attribute type="1" value="1,4,1000-1003"/>
<attribute type="1" value="*" error="114"/>
@@ -359,7 +434,12 @@
If attribute marcxml is given, the proxy will
perform MARC21 to MARCXML conversion. In this case the
type should be XML. The proxy will use
- preferred record syntax USMARC/MARC21 against the backend target.
+ preferred record syntax USMARC/MARC21 or backendtype
+ (if given) against the backend target.
+
+
+ If attribute backendtype is given, that holds the
+ record syntax to be transmitted to backend.
If attribute stylesheet is given, the proxy
@@ -393,15 +473,15 @@
..
<syntax type="usmarc"/>
<syntax type="xml" marcxml="1"
- identifier="info:srw/schema/1/marcxml-v1.1"
- <title>MARCXML<title>
- <name>marcxml<name>
- <syntax>
+ identifier="info:srw/schema/1/marcxml-v1.1"
+ <title>MARCXML<title>
+ <name>marcxml<name>
+ </syntax>
<syntax type="xml" marcxml="1" stylesheet="MARC21slim2SRWDC.xsl"
- identifier="info:srw/schema/1/dc-v1.1">
- <title>Dublin Core<title>
- <name>dc<name>
- <syntax>
+ identifier="info:srw/schema/1/dc-v1.1">
+ <title>Dublin Core<title>
+ <name>dc<name>
+ </syntax>
<syntax type="*" error="238"/>
..
</target>
@@ -440,17 +520,20 @@
cql2rpn
- The CDATA of cql2rpn refers to CQL to a RPN conversion
- file - for the server in the target section. This element
- is required for SRW/SRU searches to operate against a Z39.50
- server that doesn't support CQL. Most Z39.50 servers only support
+ The content of the cql2rpn element specifies
+ the path from the working directory to a CQL-to-RPN conversion
+ file for the server in the target section. This element
+ is required for SRW/SRU searches to operate against Z39.50
+ servers that don't support CQL. Most Z39.50 servers only support
Type-1/RPN so this is usually required.
+
+
See YAZ documentation for more information about the
CQL
to PQF conversion. See also the
pqf.properties in the etc
(or prefix/share/yazproxy)
- directory of the YAZ proxy.
+ directory of the YAZ proxy distribution.
@@ -567,81 +650,6 @@
-
-
- Query Caching
-
- Simple stateless clients often send identical Z39.50 searches
- in a relatively short period of time (e.g. in order to produce a
- results-list page, the next page,
- a single full-record, etc). And for many targets, it's
- much more expensive to produce a new result set than to
- reuse an existing one.
-
-
- The proxy tries to solve that by remembering the last query for each
- backend target, so that if an identical query is received next, it
- is turned into Present Requests rather than new Search Requests.
-
-
-
- In a future we release will will probably allows for
- an arbitrary-sized cache for targets supporting named result sets.
-
-
-
- You can enable/disable query caching using option -o.
-
-
-
-
- Record Caching
-
- As an option, the proxy may also cache result set records for the
- last search.
- The proxy takes into account the Record Syntax and CompSpec.
- The CompSpec includes simple element set names as well.
- By default the cache is 200000 bytes per session.
-
-
-
-
- Query Validation
-
- The Proxy may also be configured to trap particular attributes in
- Type-1 queries and send Bib-1 diagnostics back to the client without
- even consulting the backend target. This facility may be useful if
- a target does not properly issue diagnostics when unsupported attributes
- are send to it.
-
-
-
-
- Record Syntax Validation
-
- The proxy may be configured to accept, reject or convert records.
- When accepted, the target passes search/present requests to the
- backend target under the assumption that the target can honor the
- request (In fact it may not do that). When a record is rejected because
- the record syntax is "unsupported" the proxy returns a diagnostic to the
- client. Finally, the proxy may convert records.
-
-
- The proxy can convert from MARC to MARCXML and thereby offer an
- XML version of any MARC record as long as it is ISO2709 encoded.
- If the proxy is compiled with libXSLT support it can also
- perform XSLT on XML.
-
-
-
-
- Other Optimizations
-
- We've had some plans to support global caching of result set records,
- but this has not yet been implemented.
-
-
-
Proxy Usage (man page)
@@ -686,9 +694,9 @@
directory etc of the distribution.
+
-
+
@@ -765,23 +773,24 @@
-
-
+
+
-
-
-
-
-
+
+
+
+
+
+
+
+
-
]]>