I'm working on a project where I would find a basic plugin system useful. Essentially, I create the base class and can provide this base class to a plugin developer. Then the developer overrides it and overrides the methods. Then this is where it becomes a bit unclear to me. How does it work from here? Where could I find documentation pertaining to the development of this type of system?
Thanks
The plugin systems I know of all use dynamic libraries. Basically, you need to define a small, effective handshake between the system kernel and the plugins. Since there is no C++ ABI, plugins must either only use a C API or use the very same compiler (and probably compiler version) as the system's kernel.
The simplest thinkable protocol would be a function, that all plugin developers would have to provide, which returns an instance of a class derived from your base class, returned as a base class pointer. (The extern "C" makes sure that function won't have a mangled name, and is thus easier to find by its name.) Something like:
extern "C" {
plugin_base* get_plugin();
}
The kernel would then try to load binaries found in designated places as dynamic libraries and attempt to find the get_plugin() function. If it succeeds, it calls this function and ends up with a loaded plugin instance.
Of course, it would be nice to also have functions to check the version of the API the plugin was compiled against vs. the version of the kernel. (You might change that base class, after all.) And you might have other functions, which return information about the plugin (or you have this as virtuals in the base class). That depends a lot on the nature of your system.
You can compile plugin as dynamic/shared library put it into plugin folder and then from your code dynamicly load all dll files from plugin folder.
You may check source code for programs like GIMP to check how they implement plugis.
Probably almost the only documentation you'll be able to find will be of existing systems.
Basically, you have two common types of plug-ins. One handles things like translations to/from some foreign file type. In this case, you typically have about three functions: one to recognize the file format, one to read and one to write it. Along with those, you'll typically have a few strings to specify a file extension.
Another possibility is something that does processing inside your program. In this case, it'll typically specify some entries to be added to your menu structure and a function to be invoked for each. In most cases you'll have at least one other function to do something with serializing its current configuration. From there it'll be up to you to decide how to expose enough of the internals of your program for it to be able to do something useful.
On Linux, a plugin is a shared library (with a .so extension) that provides one or more functions named in your plugin API. Your program opens the library with dlopen and gets pointers to the functions using dlsym and calls the functions using the pointers. The plugin can call any function that's exported publically from your program.