-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin system #339
base: master
Are you sure you want to change the base?
Plugin system #339
Conversation
A method for generating plugin IDs is needed. I would like to have something decentralized. Using uuid4 could be a good option ? To explain the importance of plugin IDs: plugins need a reliable way to declare dependencies on one another, and using names alone is not a robust long-term solution. Additionally, the plugin manager must be able to handle dependencies efficiently. It would also be worth investigating whether we can support scenarios where two plugins have circular dependencies, requiring each other. We need a way to detect if a plugin is outdated. I propose that plugin_metadata should include the current plugin API version being used by the plugin. Then, the plugin loader can simply check whether the plugin's API version is compatible with the supported API versions (using semantic versioning). I want to implement side-loading for plugins, specifically one for WASM and another for Lua. For this to work, we would need to ensure that the plugin stack can handle side-loaded plugins in a way that allows a normally loaded plugin to require a side-loaded one. This might involve allowing a plugin to load another "plugin". I don't know how we can make this work, but it would be really nice. |
Btw: The system you made looks really good! Forgot to say this: We also need to implement something like events or hooks. |
One of my main targets is to make the plugins similair to spigot plugins, they use names as the plugin identifiers and for dependencies, but having some unique id system would probably be better.
Depends on what functionality they would require from each other. Another good question is how exactly would the plugins interface with each other. I'd probably recommend a system where plugins can register certain methods or structs with the plugin manager, so that other plugins can access them.
This is definetly a good idea. It would also be nice if the plugin manager could either periodically or on startup check if any plugins have newer versions available, but this would require implementing a plugin marketplace. The plugin marketplace could also help with providing unique IDs to plugins, but this would no longer be a decentralized system. Maybe if IDs were prefixed with the provisioner of the ID (like 'market:abcd1234' or something similair)?
If I were to implement the functionality where plugins can register their methods on the manager and expose them to other plugins, this would allow us to use WASM and Lua as full plugins that could interface with other plugins as well
I am working on those now, I am primarily thinking up some efficient system for distributing these events between plugins, and a system for plugins to register events they will be listening for, so that all events dont need to be sent to all plugins |
First of all, Good Job so far this PR looks pretty promising and you put a good amount of effort into it already. For now one thing i would change is, to remove the plugin_metadata and require it in the plugins |
Hi, I have a idea for both the id handling and update. |
I saw you put |
Time spent on this PR:
Description
A plugin system using dynamic library loading. Library metadata is stored directly in the library file (
.so
,.dylib
, or.dll
) so all the server admin has to do is put the os-specific file into the plugin directory. Plugin metadata is pulled from theCargo.toml
file at compile time.This system is still in an early stage of development, I need to implement a lot of things and split up the code to make it easier to work with in the future, as well as add tests, and some other things.
TODO List
Extism (WASM) support- might not implementLua support- will be a separate prUsage
A separate crate named
pumpkin-api-macros
defines macros to simplify plugin development:There is an example plugin available at
plugins/hello-plugin-source/
Testing
Works on my machine ™️
Tested on:
Checklist
Things need to be done before this Pull Request can be merged.
cargo fmt
cargo clippy
cargo test