This PR overhauls how plugin management is handled on the agent. This new method has a number of key advantages over the original, and the first concept discussed in #4.
Plugins are now crates, which allows them to be distributed on Crates.io, other github repositories, or in a separate location on the local filesystem without any additional work on the agent.
Agent dependencies are now entirely decoupled from plugin dependencies. Both previous iterations of the plugin system required the agent to 'support' any necessary dependencies.
The agent library, containing the AgentPlugin trait and a few utilities, is now a separate crate as well. This crate could be published and added as a dependency allowing plugin authors to keep their own codebase clean of any Inquisitor code or build artifacts.
Plugins can now be versioned, and version management will be handled by cargo directly.
There is some compile time code generation, but the major issue here is the configuration files.
Further discussion to be had:
Configuration management. With this way of installing plugins, default configuration files become more difficult. We could provide a config for the base plugins, or implement some way of plugins generating their own default config at runtime.
Configuration failure. Should an unconfigured plugin be silently ignored or run a default config?
Further work to be done:
Now that we have a vector of all plugins, we can get the time remaining until the next plugin update. This would allow of to sleep the optimum amount of time rather than just 1 second. Would required a change to the AgentPlugin trait.
Overall, we get version management, dependency management, distribution, flexibility, and a cleaner and more streamlined codebase at the cost of the configuration issues mentioned above. So I've decided to go ahead and open this as a PR. No pressure to merge until after the configuration issue it sorted out.
This PR overhauls how plugin management is handled on the agent. This new method has a number of key advantages over the original, and the first concept discussed in #4.
There is some compile time code generation, but the major issue here is the configuration files.
Further discussion to be had:
Further work to be done:
Overall, we get version management, dependency management, distribution, flexibility, and a cleaner and more streamlined codebase at the cost of the configuration issues mentioned above. So I've decided to go ahead and open this as a PR. No pressure to merge until after the configuration issue it sorted out.