When WL#4102 (Service registry) is completed, plugins will be able to register and provide services. We should unify the plugin interface, building it around this concept. There should be no "plugin type" or "sub-APIs". Instead plugins will provide services to each other and the server in a uniform fashion. Changing to this new architecture can be done completely transparent and binary backward-compatible for old plugins, thanks to versioning.
A storage engine plugin, for example, CSV, will register "StorageEngine/CSV" service (or "StorageEngine.CSV" may be). A plugin may register many services, for example, InnoDB plugin may register the storage engine and all related I_S tables at once. On CREATE TABLE ... ENGINE=XXX the server will search for a "StorageEngine/XXX" service of a specific version (that the server supports). If an incompatible version is found - it's an error, CREATE TABLE will fail. But *installing* a plugin that registers a "StorageEngine/XXX" service of an incompatible version is not an error - unlike "plugin types" now services are provided to whoever will request them, and there could be another plugin that can use "StorageEngine/XXX" of that version. We'll still issue a warning when a service of an incompatible version is registered. Categories ========== StorageEngine ------------- This category is for all storage engines and by registering a handle under a this category, a storage engine is present for use by the server and/or other plugins. Replacement for the MYSQL_STORAGE_ENGINE_PLUGIN InformationSchema ----------------- This category is for all information schema tables, and by registering a handle under this category, a new information schema is made available in the server. Replacement for the MYSQL_INFORMATION_SCHEMA_PLUGIN FulltextSearch/Parser --------------------- Replacement for the MYSQL_FTPARSER_PLUGIN ---------------------- Note that MYSQL_DAEMON_PLUGIN doesn't have a "category" - it's simply a plugin that doesn't provide any services.