+
+ <section id="class-FactoryFilter">
+ <title><literal>mp::FactoryFilter</literal>
+ (<filename>factory_filter.cpp</filename>)</title>
+ <para>
+ A factory class that exists primarily to provide the
+ <literal>create()</literal> method, which takes the name of a
+ filter class as its argument and returns a new filter of that
+ type. To enable this, the factory must first be populated by
+ calling <literal>add_creator()</literal> for static filters (this
+ is done by the <literal>FactoryStatic</literal> class, see below)
+ and <literal>add_creator_dyn()</literal> for filters loaded
+ dynamically.
+ </para>
+ </section>
+
+ <section id="class-FactoryStatic">
+ <title><literal>mp::FactoryStatic</literal>
+ (<filename>factory_static.cpp</filename>)</title>
+ <para>
+ A subclass of <literal>FactoryFilter</literal> which is
+ responsible for registering all the statically defined filter
+ types. It does this by knowing about all those filters'
+ structures, which are listed in its constructor. Merely
+ instantiating this class registers all the static classes. It is
+ for the benefit of this class that <literal>struct
+ metaproxy_1_filter_struct</literal> exists, and that all the filter
+ classes provide a static object of that type.
+ </para>
+ </section>
+
+ <section id="class-filter-Base">
+ <title><literal>mp::filter::Base</literal>
+ (<filename>filter.cpp</filename>)</title>
+ <para>
+ The virtual base class of all filters. The filter API is, on the
+ surface at least, extremely simple: two methods.
+ <literal>configure()</literal> is passed an XML DOM tree representing
+ that part of the configuration file that pertains to this filter
+ instance, and is expected to walk that tree extracting relevant
+ information. And <literal>process()</literal> processes a
+ package (see below). That surface simplicity is a bit
+ misleading, as <literal>process()</literal> needs to know a lot
+ about the <literal>Package</literal> class in order to do
+ anything useful.
+ </para>
+ </section>
+
+ <section id="class-AuthSimple">
+ <title><literal>mp::filter::AuthSimple</literal>,
+ <literal>Backend_test</literal>, etc.
+ (<filename>filter_auth_simple.cpp</filename>,
+ <filename>filter_backend_test.cpp</filename>, etc.)</title>
+ <para>
+ Individual filters. Each of these is implemented by a header and
+ a source file, named <filename>filter_*.hpp</filename> and
+ <filename>filter_*.cpp</filename> respectively. All the header
+ files should be pretty much identical, in that they declare the
+ class, including a private <literal>Rep</literal> class and a
+ member pointer to it, and the two public methods.
+ </para>
+ <para>
+ The source file for each filter needs to supply:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A definition of the private <literal>Rep</literal> class.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Some boilerplate constructors and destructors.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A <literal>configure()</literal> method that uses the
+ appropriate XML fragment.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Most important, the <literal>process()</literal> method that
+ does all the actual work.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="class-Package">
+ <title><literal>mp::Package</literal>
+ (<filename>package.cpp</filename>)</title>
+ <para>
+ Represents a package on its way through the series of filters
+ that make up a route. This is essentially a Z39.50 or SRU APDU
+ together with information about where it came from, which is
+ modified as it passes through the various filters.
+ </para>
+ </section>
+
+ <section id="class-Pipe">
+ <title><literal>mp::Pipe</literal>
+ (<filename>pipe.cpp</filename>)</title>
+ <para>
+ This class provides a compatibility layer so that we have an IPC
+ mechanism that works the same under Unix and Windows. It's not
+ particularly exciting.
+ </para>
+ </section>
+
+ <section id="class-RouterChain">
+ <title><literal>mp::RouterChain</literal>
+ (<filename>router_chain.cpp</filename>)</title>
+ <para>
+ ### to be written
+ </para>
+ </section>
+
+ <section id="class-RouterFleXML">
+ <title><literal>mp::RouterFleXML</literal>
+ (<filename>router_flexml.cpp</filename>)</title>
+ <para>
+ ### to be written
+ </para>
+ </section>
+
+ <section id="class-Session">
+ <title><literal>mp::Session</literal>
+ (<filename>session.cpp</filename>)</title>
+ <para>
+ ### to be written
+ </para>
+ </section>
+
+ <section id="class-ThreadPoolSocketObserver">
+ <title><literal>mp::ThreadPoolSocketObserver</literal>
+ (<filename>thread_pool_observer.cpp</filename>)</title>
+ <para>
+ ### to be written
+ </para>
+ </section>
+
+ <section id="class-util">
+ <title><literal>mp::util</literal>
+ (<filename>util.cpp</filename>)</title>
+ <para>
+ A namespace of various small utility functions and classes,
+ collected together for convenience. Most importantly, includes
+ the <literal>mp::util::odr</literal> class, a wrapper for YAZ's
+ ODR facilities.
+ </para>
+ </section>
+
+ <section id="class-xml">
+ <title><literal>mp::xml</literal>
+ (<filename>xmlutil.cpp</filename>)</title>
+ <para>
+ A namespace of various XML utility functions and classes,
+ collected together for convenience.
+ </para>
+ </section>