Component Subsystem

The component subsystem is designed to overcome some of the architectural issues of the plugin subsystem, namely:

1. Plugins can only "talk" to the server and not with other plugins
2. Plugins have access to the server symbols and can call them directly, i.e. no encapsulation
3. There's no explicit set of dependencies of a plugin, thus it's hard to initialize them properly
4. Plugins require a running server to operate.

The component infrastructure aims at allowing the MySQL server subsystems to be encapsulated into a set of logical components. Additional components may be added to a running server to extend its functionality.

Components can be linked either dynamically or statically.

Each component will provide implementations of an extensive set of named APIs, services, that other components can consume. To facilitate this there will be a registry of all services available to all components.

Each component will communicate with other components only through services and will explicitly state the services it provides and consumes.

The infrastructure will enable components to override and complement other components through re-implementing the relevant service APIs.

Once there's a critical mass of such components exposing their functionality and consuming the services they need through named service APIs this will allow additional loadable components to take advantage of all the functionality they need without having to carve in specialized APIs into the monolithic server code for each new need.

The infrastructure described here is mostly orthogonal to the ongoing activity on modularizing the MySQL Server. However, properly defined modules and interfaces in the Server, allows server functionality to easily be exposed as services where it makes sense.

Component Subsystem Concepts

Service Inventory

To the Component Services Inventory