Ways to Register a Plugin
In a plugin architecture, how does the app know which plugins are available? I’m interested in how the app discovers new plugins it did not already know about and learns its capabilities.
- I assume that once an app knows about a plugin (that the user wants it to us) it keeps track of it somehow, doesn’t matter how.
Let us count the ways:
-
App uses some kind of machine-local registry (on Windows, the Registry). Plugin installer adds proper entries to the registry. (This is the way COM components worked.)
-
App has some kind of “install plugin” API - plugin’s installer calls it to let app know it is there, providing its capabilities.
-
App has a UI feature that let’s user navigate his filesystem, and select a plugin, and then the app knows about it and that it is a plugin and can load it and ask it its capabilities (user approved that).
-
App has a UI feature that let’s user navigate some plugin registry (out on the web), and select a plugin, then the app knows about it (and downloads it and installs it and gets its capabilities from the registry or from the plugin itself by loading it and calling it.
-
App has a plugin “search path” on the filesystem and goes looking for plugins on that search path.
- It finds “manifest” files - text files in some schema - that describe a plugin right next to the plugin file, where they’re associated by the same filename but different extensions (or something like that).
- They have a distinguished name (e.g. end in
.dllor.so). Or, everything on the search path is assumed to possibly be a plugin.- App loads each one as an executable, checks to make sure it has a particular external symbol that will provide the plugin’s capabilities, then calls it (or alternatively, doesn’t check and relies on the operating system to signal an error if the symbol doesn’t exist).
- A bit risky, much? Loading an arbitrary executable you find into your process as an executable and calling it?
- App loads each one as a resource container and uses OS APIs to extract a particular resource which is the manifest describing the plugin.
- (Windows has a special way to load an executable as a resource container without actually making it be an executable part of your process. )
- App loads each one as a datafile and just looks inside of it to find a distinguished string - e.g., a manifest surrounded by known banners not likely to be there by accident.
- App loads each one as an executable, checks to make sure it has a particular external symbol that will provide the plugin’s capabilities, then calls it (or alternatively, doesn’t check and relies on the operating system to signal an error if the symbol doesn’t exist).
In the cases where the app is using a DLL/so directly it can determine that that executable code is legitimate in some operating system defined way.
- Well, for Windows it looks for a valid code signature, same for MacOS and Solaris, for Linux apparently all there is is a bunch of excuses why it isn’t necessary to support code signing at all, e.g., here from a guy who actually wrote such a code-signing facility for Linux.
Reason I’ve been thinking about this is my blockchain application will have a plugin architecture for modules (though some will be built-in). I’m thinking of going with the manifest file (probably JSON), surrounded by banners, embedded in the executable as a resource (on Windows) or just embedded in it (on Linux).