The 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 via 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 allows for 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 via 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 parsing 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.
In some respects, the plugin API is similar to the older user-defined function (UDF) API that it supersedes, but the plugin API has several advantages over the older interface. For example, UDFs had no versioning information. Also, the newer plugin interface eliminates the security issues of the older UDF interface. The older interface for writing nonplugin UDFs allowed libraries to be loaded from any directory searched by the system's dynamic linker, and the symbols that identified the UDF library were relatively nonspecific.
User Comments
Add your own comment.