4.2 Plugin API Characteristics

The server plugin API has these characteristics:

• All plugins have several things in common.

  Each plugin has a name that it can be referred to in SQL statements, as well as other metadata such as an author and a description that provide other information. This information can be examined in the INFORMATION_SCHEMA.PLUGINS table or using the SHOW PLUGINS statement.

• The plugin framework is extendable to accommodate different kinds of plugins.

  Although some aspects of the plugin API are common to all types of plugins, the API also permits type-specific interface elements so that different types of plugins can be created. A plugin with one purpose can have an interface most appropriate to its own requirements and not the requirements of some other plugin type.

  Interfaces for several types of plugins exist, such as storage engines, full-text parser, and INFORMATION_SCHEMA tables. Others can be added.

• Plugins can expose information to users.

  A plugin can implement system and status variables that are available through the SHOW VARIABLES and SHOW STATUS statements.

• The plugin API includes versioning information.

  The version information included in the plugin API enables a plugin library and each plugin that it contains to be self-identifying with respect to the API version that was used to build the library. If the API changes over time, the version numbers will change, but a server can examine a given plugin library's version information to determine whether it supports the plugins in the library.

  There are two types of version numbers. The first is the version for the general plugin framework itself. Each plugin library includes this kind of version number. The second type of version applies to individual plugins. Each specific type of plugin has a version for its interface, so each plugin in a library has a type-specific version number. For example, a library containing a full-text parser plugin has a general plugin API version number, and the plugin has a version number specific to the full-text plugin interface.

• The plugin API implements security restrictions.

  A plugin library must be installed in a specific dedicated directory for which the location is controlled by the server and cannot be changed at runtime. Also, the library must contain specific symbols that identify it as a plugin library. The server will not load something as a plugin if it was not built as a plugin.

• Plugins have access to server services.

  The services interface exposes server functionality that plugins can access using ordinary function calls. For details, see MySQL Plugin Services.

In some respects, the server plugin API is similar to the older loadable function API that it supersedes, but the plugin API has several advantages over the older interface. For example, loadable functions had no versioning information. Also, the newer plugin interface eliminates the security issues of the older loadable function interface. The older interface for writing nonplugin loadable functions permitted libraries to be loaded from any directory searched by the system's dynamic linker, and the symbols that identified the loadable function library were relatively nonspecific.

The client plugin API has similar architectural characteristics, but client plugins have no direct access to the server the way server plugins do.