+yp2::filter::Base
+-----------------
+
+The virtual base class of all filters. The filter API is, on the
+surface at least, extremely simple: two methods. configure() is
+passed a 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 process() processes a
+Package (see below). That surface simplicitly is a bit misleading, as
+process() needs to know a lot about the Package class in order to do
+anything useful.
+
+yp2::filter::AuthSimple, Backend_test, FrontendNet, etc.
+--------------------------------------------------------
+
+Individual filters. Each of these is implemented by a header and a
+source file, named filter_*.hpp and filter_*.cpp respectively. All
+the header files should be pretty much identical, in that they declare
+the class, including a private Rep class and a member pointer to it,
+and the two public methods. The only extra information in any filter
+header is additional private types and members (the latter should
+really all be in the Rep anyway).
+
+The source file for each filter needs to supply:
+- a definition of the private Rep class
+- some boilerplate constructors and destructors
+- a configure() method that uses the appropriate XML fragment
+- most important, the prcoess() method that does all the actual work.
+
+In a better world, each of the filters (nine so far) would be
+documented separately. Very, very briefly, though:
+- auth_simple: authentication against a plain-text file
+- backend_test: trivial ztest-like dummy hardwired back-end
+- frontend_net: receives incoming Z39.50 and SRW PSUs
+- log: writes log messages
+- multi: fans out searches to multiple back-ends
+- session_shared: global sharing of cached result-sets
+- template: NOT TO BE USED: just a template source file for new filters
+- virt_db: chooses which server/db to use based on database name
+- z3950_client: forwards PDUs to a nominated Z39.50 server
+
+### What is "filter_dl.cpp"? It's to do with dynamic loading, but in
+what way and to what extent does it function as a filter?
+
+See the file "filters" for more information.
+
+
+yp2::Package
+------------
+
+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.
+
+
+yp2::Pipe
+---------
+
+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.
+
+
+yp2::Router and yp2::RouterChain
+--------------------------------
+
+###
+
+
+yp2::RouterFleXML
+-----------------
+
+###
+
+
+yp2::Session
+------------
+
+###
+
+yp2::ThreadPoolSocketObserver
+-----------------------------
+
+###
+
+yp2::util
+---------
+
+A namespace of various small utility functions and classes, collected
+together for convenience. Most importantly, includes the
+yp2::util::odr class, a wrapper for YAZ's ODR facilities.
+
+
+yp2::xml
+---------
+
+A namespace of various XML utility functions and classes, collected
+together for convenience.