Plugin System #18
Description
High level
Implement a plugin system within Platypus to allow modification of behavior and data handling through the use of an internal plugin API, which also disallows exposure of secrets. This would primarily be on the master node side, as custom clients would be preferred rather than implementing the same plugin system into the client.
Possibilities
- Configuration-based plugins
- Easier to implement code-wise
- Lower barrier of entry
- Could get complex fast
- Rigid, not as dynamic
- Scripting-based plugins
- Harder to implement code-wise
- Depends on final scripting language
- Much more flexible, deeper customization
- Higher barrier to entry as a trade off
- Harder to implement code-wise
Configuration-based
Configuration would come in the form of .yaml files which would be located within a plugins/plugin_name directory. Platypus would seek through these directories and load the plugin.yaml file, which can in turn reference other yaml files. These can define rules for how Platypus should behave or handle incoming data from clients. This would take some time to completely flesh out and sort of the syntax of.
No the ideal solution, but is an option if it can be fleshed out completely.
Scripting-based
This is the ideal solution, which would implement a language interpreter into Platypus for X scripting language, with some slight modifications to expose hooks/events allowing modification of data handling as it comes in from either the web clients or server clients.
The language would have to be interpreted, as I'm not entirely sure how implementation of a compiled language would work. Right now, the choice is between Lua and Python, however other options, or even a custom language, can be considered. These would likely have to couple with a .yaml file to expose some metadata for the plugin.