Skip to content
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 #18

Open
gmemstr opened this issue May 7, 2019 · 2 comments
Open

Plugin System #18

gmemstr opened this issue May 7, 2019 · 2 comments
Projects

Comments

@gmemstr
Copy link
Owner

gmemstr commented May 7, 2019

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

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.

@gmemstr gmemstr pinned this issue May 8, 2019
@gmemstr gmemstr unpinned this issue Jun 27, 2019
@gmemstr gmemstr closed this as completed Jun 27, 2019
@gmemstr
Copy link
Owner Author

gmemstr commented Jun 27, 2019

Closed until concept can be fully fleshed out and I can justify the effort to implement it.

@gmemstr
Copy link
Owner Author

gmemstr commented Aug 8, 2019

Opening this back up, I think we can use https://github.com/containous/yaegi to implement this!

@gmemstr gmemstr reopened this Aug 8, 2019
@gmemstr gmemstr added this to To do in 4.0 Aug 8, 2019
@gmemstr gmemstr moved this from To do to In progress in 4.0 Aug 22, 2019
gmemstr added a commit that referenced this issue Aug 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
4.0
  
In progress
Development

No branches or pull requests

1 participant