You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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
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 theplugin.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.
The text was updated successfully, but these errors were encountered: