2. Individual classes
Prev | Chapter 9. Classes in the Metaproxy source code | Next

## 2. Individual classes

The classes making up the Metaproxy application are here listed by class-name, with the names of the source files that define them in parentheses.

### 2.1. `mp::FactoryFilter` (`factory_filter.cpp`)

A factory class that exists primarily to provide the `create()` 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 `add_creator()` for static filters (this is done by the `FactoryStatic` class, see below) and `add_creator_dyn()` for filters loaded dynamically.

### 2.2. `mp::FactoryStatic` (`factory_static.cpp`)

A subclass of `FactoryFilter` 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 `struct metaproxy_1_filter_struct` exists, and that all the filter classes provide a static object of that type.

### 2.3. `mp::filter::Base` (`filter.cpp`)

The virtual base class of all filters. The filter API is, on the surface at least, extremely simple: two methods. `configure()` 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 `process()` processes a package (see below). That surface simplicity is a bit misleading, as `process()` needs to know a lot about the `Package` class in order to do anything useful.

### 2.4. `mp::filter::AuthSimple`, `Backend_test`, etc. (`filter_auth_simple.cpp`, `filter_backend_test.cpp`, 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 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 `process()` method that does all the actual work.

### 2.5. `mp::Package` (`package.cpp`)

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.

### 2.6. `mp::Pipe` (`pipe.cpp`)

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.

### 2.7. `mp::RouterChain` (`router_chain.cpp`)

### to be written

### 2.8. `mp::RouterFleXML` (`router_flexml.cpp`)

### to be written

### 2.9. `mp::Session` (`session.cpp`)

### to be written

### 2.10. `mp::ThreadPoolSocketObserver` (`thread_pool_observer.cpp`)

### to be written

### 2.11. `mp::util` (`util.cpp`)

A namespace of various small utility functions and classes, collected together for convenience. Most importantly, includes the `mp::util::odr` class, a wrapper for YAZ's ODR facilities.

### 2.12. `mp::xml` (`xmlutil.cpp`)

A namespace of various XML utility functions and classes, collected together for convenience.

Prev | Up | Next
Chapter 9. Classes in the Metaproxy source code | Home | 3. Other Source Files