-->
<!NOTATION PDF SYSTEM "PDF">
]>
-<!-- $Id: book.xml,v 1.46 2007-01-05 10:56:17 marc Exp $ -->
+<!-- $Id: book.xml,v 1.47 2007-01-08 12:27:27 marc Exp $ -->
<book id="metaproxy">
<bookinfo>
<title>Metaproxy - User's Guide and Reference</title>
<literal>load_balance</literal> filter is assuming that
all backend targets have equal content, and chooses the backend
with least load cost for a new session.
+ <warning>
+ <para>
+ This filter is experimental and yet not mature for heavy load
+ production sites.
+ </para>
+ </warning>
</para>
</section>
and present requests, and wraps the
received hit counts and XML records into suitable SRU response
messages.
- The <literal>sru_z3950</literal> filter does only process SRU
- GET/POST/SOAP explain requests in a very crude fashion, returning
- the absolute minimum required by the standard. Full ZeeReX
- explain support is added by including the
- <literal>zeerex_explain</literal> filter before the
- <literal>sru_z3950</literal> filter.
+ The <literal>sru_z3950</literal> filter processes also SRU
+ GET/POST/SOAP explain requests, returning
+ either the absolute minimum required by the standard, or a full
+ pre-defined ZeeReX explain record.
+ See the
+ <ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
+ standard pages and the
+ <ulink url="&url.sru.explain;">SRU Explain</ulink> pages
+ for more information on the correct explain syntax.
+ SRU scan requests are not supported yet.
</para>
</section>
(mp::filter::ZeerexExplain)</title>
<para>
This filter acts as a sink for
- SRU GET/POST/SOAP explain requests, returning a static ZeeReX
+ Z39.50 explain requests, returning a static ZeeReX
Explain XML record from the config section. All other packages
- are passed through, including SRU GET/POST/SOAP searchRetrieve
- requests, which are handled by a following
- <literal>sru_z3950</literal> filter.
+ are passed through.
See the
<ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
- standard pages and the
- <ulink url="&url.sru.explain;">SRU Explain</ulink> pages
+ standard pages
for more information on the correct explain syntax.
</para>
+ <warning>
+ <para>
+ This filter is not yet completed.
+ </para>
+ </warning>
</section>
<para>
If Metaproxy is an interpreter providing operations on packages, then
its configuration file can be thought of as a program for that
- interpreter. Configuration is by means of a single file, the name
+ interpreter. Configuration is by means of a single XML file, the name
of which is supplied as the sole command-line argument to the
<command>metaproxy</command> program. (See
<link linkend="progref">the reference guide</link>
below for more information on invoking Metaproxy.)
</para>
- <para>
- The configuration files are written in XML. (But that's just an
- implementation detail - they could just as well have been written
- in YAML or Lisp-like S-expressions, or in a custom syntax.)
- </para>
</section>
<section id="overview.xml.structure">
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
"http://www.oasis-open.org/docbook/xml/4.1/docbookx.dtd" [
<!ENTITY copyright SYSTEM "copyright.xml">
+ <!ENTITY % common SYSTEM "common/common.ent">
+ %common;
]>
-<!-- $Id: sru_z3950.xml,v 1.3 2007-01-05 10:56:17 marc Exp $ -->
+<!-- $Id: sru_z3950.xml,v 1.4 2007-01-08 12:27:27 marc Exp $ -->
<refentry>
<refmeta>
<refentrytitle>sru_z3950</refentrytitle>
<refnamediv>
<refname>sru_z3950</refname>
- <refpurpose>transforming SRU web service requests to Z3950 metaproxy packages</refpurpose>
+ <refpurpose>transforming SRU web service requests to Z3950 Metaproxy packages</refpurpose>
</refnamediv>
<refsect1><title>DESCRIPTION</title>
<para>
- The <literal>sru_z3950</literal> metaproxy filter transforms valid
+ The <literal>sru_z3950</literal> Metaproxy filter transforms valid
SRU GET/POST/SOAP requests to Z3950 requests, and wraps the
received hit counts and XML records into suitable SRU response messages.
</para>
<para>
- It supports only the SRU <literal>searchRetrieve</literal> operation, which
+ Multiple database elements defining the names of the accepted
+ databases are allowed in the configuration file. Each
+ of them must contain their own explain record, or must be empty.
+ Notice that explain
+ records come in SRU and Z39.50 flavors, and this filter requires
+ the SRU version. See the
+ <ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
+ standard pages and the
+ <ulink url="&url.sru.explain;">SRU Explain</ulink> pages
+ for more information.
+ </para>
+ <para>
+ All Z39.50 packages and all HTTP packages that do not resolve to
+ one configured database name are passed unaltered to the next
+ filters on the route.
+ </para>
+ <para>
+ The SRU <literal>explain</literal> operation is supported,
+ returning either the absolute minimum required by the standard, or
+ a full pre-defined ZeeReX explain record.
+ </para>
+ <para>
+ It supports the SRU <literal>searchRetrieve</literal> operation, which
is transformed into successive Z3950 <literal>init</literal>,
<literal>search</literal> and <literal>present</literal> requests.
</para>
The SRU <literal>scan</literal> operation is not supported.
</para>
<para>
- The SRU <literal>explain</literal> operation is not supported.
- A configuration for a full SRU server needs to prepend the
- <literal>zeerex_explain</literal> filter in front of this
- <literal>sru_z3950</literal> to serve explain requests.
- </para>
- <para>
This filter does not handle CQL-to-PQF translations. In case that
- the backends do not understand CQL, you need to prepend the
+ the backends do not understand CQL, you need to append the
<literal>cql_pqf</literal> metaproxy filter. This filter
still needs to be implemented.
</para>
<para>
A typical configuration looks like this:
<screen><![CDATA[
- <filter type="sru_z3950"/>
+ <filter type="sru_z3950">
+ <database name="Default">
+ <explain xmlns="http://explain.z3950.org/dtd/2.0/">
+ ...
+ </explain>
+ </database>
+ <database name="Dummy">
+ </filter>
+
]]>
</screen>
</para>
<!ENTITY % common SYSTEM "common/common.ent">
%common;
]>
-<!-- $Id: zeerex_explain.xml,v 1.1 2007-01-05 10:56:17 marc Exp $ -->
+<!-- $Id: zeerex_explain.xml,v 1.2 2007-01-08 12:27:27 marc Exp $ -->
<refentry>
<refmeta>
<refentrytitle>zeerex_explain</refentrytitle>
<refnamediv>
<refname>zeerex_explain</refname>
- <refpurpose>answering SRU web service explain requests</refpurpose>
+ <refpurpose>answering Z39.50 ZeeReX explain requests</refpurpose>
</refnamediv>
<refsect1><title>DESCRIPTION</title>
<para>
- The <literal>zeerex_explain</literal> metaproxy filter
- answers valid SRU GET/POST/SOAP explain requests, returning a
+ The <literal>zeerex_explain</literal> Metaproxy filter
+ answers valid Z30.50 explain requests, returning a
static ZeeReX Explain XML record from the config section. All other
packages are passed through.
</para>
Multiple database elements defining the names of the accepted
databases are allowed in the configuration file. Each
of them must contain their own explain record. Notice that explain
- records come in SRU and Z3950 flavours, and this filter requires
- the SRU version. See the
+ records come in SRU and Z39.50 flavours, and this filter requires
+ the Z39.50 version. See the
<ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
standard pages and the
<ulink url="&url.sru.explain;">SRU Explain</ulink> pages
for more information.
</para>
- <para>
- A configuration for a full SRU server needs to line up a
- <literal>zeerex_explain</literal> filter, a
- <literal>cql_pqf</literal> (not implemented yet) filter, and a
- <literal>sru_z3950</literal> after each other.
- </para>
</refsect1>
<refsect1><title>EXAMPLES</title>
<para>
<ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
</para>
- <para>
- <ulink url="&url.sru.explain;">SRU Explain</ulink>
- </para>
</refsect1>
©right;
projects / metaproxy-moved-to-github.git / commitdiff