+ <section>
+ <title><literal>auth_simple</literal>
+ (mp::filter::AuthSimple)</title>
+ <para>
+ Simple authentication and authorisation. The configuration
+ specifies the name of a file that is the user register, which
+ lists <varname>username</varname>:<varname>password</varname>
+ pairs, one per line, colon separated. When a session begins, it
+ is rejected unless username and passsword are supplied, and match
+ a pair in the register. The configuration file may also specific
+ the name of another file that is the target register: this lists
+ lists <varname>username</varname>:<varname>dbname</varname>,<varname>dbname</varname>...
+ sets, one per line, with multiple database names separated by
+ commas. When a search is processed, it is rejected unless the
+ database to be searched is one of those listed as available to
+ the user.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>backend_test</literal>
+ (mp::filter::Backend_test)</title>
+ <para>
+ A partial sink that provides dummy responses in the manner of the
+ <literal>yaz-ztest</literal> Z39.50 server. This is useful only
+ for testing. Seriously, you don't need this. Pretend you didn't
+ even read this section.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>bounce</literal>
+ (mp::filter::Bounce)</title>
+ <para>
+ A sink that swallows <emphasis>all packages</emphasis>,
+ and returns them almost unprocessed.
+ It never sends any package of any type further down the row, but
+ sets Z39.50 packages to Z_Close, and HTTP_Request packages to
+ HTTP_Response err code 400 packages, and adds a suitable bounce
+ message.
+ The bounce filter is usually added at end of each filter chain
+ config.xml to prevent infinite hanging of for example HTTP
+ requests packages when only the Z39.50 client partial sink
+ filter is found in the
+ route.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>frontend_net</literal>
+ (mp::filter::FrontendNet)</title>
+ <para>
+ A source that accepts Z39.50 connections from a port
+ specified in the configuration, reads protocol units, and
+ feeds them into the next filter in the route. When the result is
+ revceived, it is returned to the original origin.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>http_file</literal>
+ (mp::filter::HttpFile)</title>
+ <para>
+ A partial sink which swallows only HTTP_Request packages, and
+ returns the contents of files from the local
+ filesystem in response to HTTP requests.
+ It lets Z39.50 packages and all other forthcoming package types
+ pass untouched.
+ (Yes, Virginia, this
+ does mean that Metaproxy is also a Web-server in its spare time. So
+ far it does not contain either an email-reader or a Lisp
+ interpreter, but that day is surely coming.)
+ </para>
+ </section>
+
+ <section>
+ <title><literal>log</literal>
+ (mp::filter::Log)</title>
+ <para>
+ Writes logging information to standard output, and passes on
+ the package unchanged. A log file name can be specified, as well
+ as multiple different logging formats.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>multi</literal>
+ (mp::filter::Multi)</title>
+ <para>
+ Performs multi-database searching.
+ See
+ <link linkend="multidb">the extended discussion</link>
+ of virtual databases and multi-database searching below.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>query_rewrite</literal>
+ (mp::filter::QueryRewrite)</title>
+ <para>
+ Rewrites Z39.50 Type-1 and Type-101 (``RPN'') queries by a
+ three-step process: the query is transliterated from Z39.50
+ packet structures into an XML representation; that XML
+ representation is transformed by an XSLT stylesheet; and the
+ resulting XML is transliterated back into the Z39.50 packet
+ structure.
+ </para>
+ </section>
+
+
+ <section>
+ <title><literal>record_transform</literal>
+ (mp::filter::RecordTransform)</title>
+ <para>
+ This filter acts only on Z3950 present requests, and let all
+ other types of packages and requests pass untouched. It's use is
+ twofold: blocking Z3950 present requests, which the backend
+ server does not understand and can not honour, and transforming
+ the present syntax and elementset name according to the rules
+ specified, to fetch only exisitng record formats, and transform
+ them on the fly to requested record syntaxes.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>sru_z3950</literal>
+ (mp::filter::SRUtoZ3950)</title>
+ <para>
+ This filter transforms valid
+ SRU/GET or SRU/SOAP requests to Z3950 requests, and wraps the
+ recieved hit counts and XML records into suitable SRU response messages.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>session_shared</literal>
+ (mp::filter::SessionShared)</title>
+ <para>
+ When this is finished, it will implement global sharing of
+ result sets (i.e. between threads and therefore between
+ clients), yielding performance improvements especially when
+ incoming requests are from a stateless environment such as a
+ web-server, in which the client process representing a session
+ might be any one of many. However:
+ </para>
+ <warning>
+ <para>
+ This filter is not yet completed.
+ </para>
+ </warning>
+ </section>
+
+ <section>
+ <title><literal>template</literal>
+ (mp::filter::Template)</title>
+ <para>
+ Does nothing at all, merely passing the packet on. (Maybe it
+ should be called <literal>nop</literal> or
+ <literal>passthrough</literal>?) This exists not to be used, but
+ to be copied - to become the skeleton of new filters as they are
+ written. As with <literal>backend_test</literal>, this is not
+ intended for civilians.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>virt_db</literal>
+ (mp::filter::VirtualDB)</title>
+ <para>
+ Performs virtual database selection: based on the name of the
+ database in the search request, a server is selected, and its
+ address added to the request in a <literal>VAL_PROXY</literal>
+ otherInfo packet. It will subsequently be used by a
+ <literal>z3950_client</literal> filter.
+ See
+ <link linkend="multidb">the extended discussion</link>
+ of virtual databases and multi-database searching below.
+ </para>
+ </section>
+
+ <section>
+ <title><literal>z3950_client</literal>
+ (mp::filter::Z3950Client)</title>
+ <para>
+ A partial sink which swallows only Z39.50 packages.
+ It performs Z39.50 searching and retrieval by proxying the
+ packages that are passed to it. Init requests are sent to the
+ address specified in the <literal>VAL_PROXY</literal> otherInfo
+ attached to the request: this may have been specified by client,
+ or generated by a <literal>virt_db</literal> filter earlier in
+ the route. Subsequent requests are sent to the same address,
+ which is remembered at Init time in a Session object.
+ HTTP_Request packages and all other forthcoming package types
+ are passed untouched.
+ </para>