-
Notifications
You must be signed in to change notification settings - Fork 2
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 #9
Comments
Some things you might want to add: Plugins should also be able to add ircv3 capabilities (CAP), and the treatment of those plugins might be different. There is no reason to load a plugin with a specific CAP, if the server doesn't support it. Also as a question: what would happen if a plugin provides more than one CAP? Should that be allowed? And If it is, how to separate the capabilities that are supported by the server from those that aren't? The easiest might be to just not allow it, or maybe to bind hooks or similar to a specific CAP, e.g. "only register this hook to the network if it supports the CAP". Pseudo: |
A few tools I found: None of these seem to have any dependency loading or unloading/reloading mechanics. So we either need to look more or see if one of them is easily extensible and fit for our purpose. Note: I don't particularly like any of them. |
In order to understand what our plugin engine should be able to do, we have to consider what typical (or non-typical) bot functions you usually see on IRC. A list of the things I came up with from the top of my head. I use the
|
re CAPs: I'm thinking of having a "request_capabilities" hook where plugins get handed a set of the provided capabilities by the network and can return a set of those they want to request. The plugin manager joins the sets and sends them off as a request to the server. Supporting multiple CAPs wouldn't be an issue that way. There should probably be an attribute for the available and active capabilities for each connection so that plugins can access that. Filtering a hook to only apply if a certain CAP is active should be trivial then. We could provide some of these more advanced hooks as a plugin or add everything to core, idk. Also note that there is a CAP that allows updating the network's available CAPs (mostly useful for bouncers I suppose). |
I wrote down my general idea of plugins in our wiki: https://github.com/chireiden/shanghai/wiki/Plugins Please review and comment or ask questions. I put hot-reloading and depending on pypi packages on-hold as they are not required for the basic concept. |
Regarding Hook priority: I'd think that a plugin that depends on another plugin might want to ensure that certain hooks are always executed after (or maybe even before) the same hooks of the other plugin, without knowing the specific hook priority of the plugin it depends on. E.g. plugin A depends on plugin B, and plugin B hooks into, let's say, Simply using priorities might not be sufficient. If the developer of plugin B decides to change the priorities, plugin A has to be changed as well. I have no idea how to do that though, maybe every registered hook can be accessed via a name? Plugin B plugin key might be "pluginb" and it registered the hook "privmsg". So plugin A might be able to say "please register my Pseudo: |
That would make things complex for a couple reasons.
|
this is a changing post with our todo list
Plugins should:
For the future:
Questions:
The text was updated successfully, but these errors were encountered: