Architecture of libmd

The libmd library uses a plugin architecture in which independent plugins support different sets of metadata fields. When a client requests metadata, the library extracts it using one or more plugins and then returns the set of filled-in metadata fields to the client.

The library is implemented in three layers:

Data processing

This layer:

• stores and updates the plugin ratings for metadata fields from specific media file types
• collates (i.e., combines and orders) the metadata field values returned from plugins

Plugin management

This layer:

• parses the configuration file to learn which library files implement the plugins and to read the preference order for various file types
• loads, initializes, and unloads plugins

Plugins

This layer consists of many Metadata Provider (MDP) plugins, each of which:

• manages communication sessions for responding to metadata requests and for reporting errors
• rates itself on its ability to retrieve the requested metadata fields
• retrieves metadata by extracting media information from the named item (media file)

This design lets libmd offer a common, high-level interface for extracting metadata from many file types on many device types. Clients need to name only a media file and the metadata fields they want and libmd then invokes the necessary MDP plugins to read the metadata and returns the extracted metadata fields to the client.

Each MDP fills in as many fields as it can. The order that libmd uses to invoke the MDPs depends on the plugin preferences stated in the configuration file. The preferential order for plugins can vary from one file type to another.