It's useful to think of Metaproxy as an interpreter providing a small number of primitives and operations, but operating on a very complex data type, namely the ``package''.

A package represents a Z39.50 or SRU/W request (whether for Init, Search, Scan, etc.) together with information about where it came from. Packages are created by front-end filters such as frontend_net (see below), which reads them from the network; other front-end filters are possible. They then pass along a route consisting of a sequence of filters, each of which transforms the package and may also have side-effects such as generating logging. Eventually, the route will yield a response, which is sent back to the origin.

There are many kinds of filter: some that are defined statically as part of Metaproxy, and others may be provided by third parties and dynamically loaded. They all conform to the same simple API of essentially two methods: configure() is called at startup time, and is passed an XML DOM tree representing that part of the configuration file that pertains to this filter instance: it is expected to walk that tree extracting relevant information; and process() is called every time the filter has to processes a package.

While all filters provide the same API, there are different modes of functionality. Some filters are sources: they create packages (frontend_net); others are sinks: they consume packages and return a result (backend_test, bounce, http_file, z3950_client); the others are true filters, that read, process and pass on the packages they are fed (auth_simple, log, multi, query_rewrite, record_transform, session_shared, sru_z3950, template, virt_db).