Was talking with @MrBenC in the channel when the subject of a possible inter-module communication and dependency system came up. He had an idea for what it could be useful for, as do I, as far as some use cases go.
The essential ideas are adding the ability for modules to define a version for themselves, depend or soft depend on other modules, and be able to exchange messages between them.
Rather than putting the result of a bit of back and forth in here, I've put it into a gist here to facilitate others modifying it.
Comments would be appreciated. Once a more concrete foundation is set, and the znc developers can agree on if it'd be a good idea or not, I (or someone else) could take a crack at making it a PR.
Was talking with @MrBenC in the channel when the subject of a possible inter-module communication and dependency system came up. He had an idea for what it could be useful for, as do I, as far as some use cases go.
The essential ideas are adding the ability for modules to define a version for themselves, depend or soft depend on other modules, and be able to exchange messages between them.
Rather than putting the result of a bit of back and forth in here, I've put it into a gist [here](https://gist.github.com/NuclearW/d5c76a26deed4dcb8617) to facilitate others modifying it.
Comments would be appreciated. Once a more concrete foundation is set, and the znc developers can agree on if it'd be a good idea or not, I (or someone else) could take a crack at making it a PR.
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3373781-inter-module-communication-dependency-versioning-proposal?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:38955130 -->
Inter-module communication is very needed since ages ago.
Too bad I can't comment directly on gist.
What's the point of version, and why it should be different from ZNC version?
OnModuleLoading had a somewhat different use case...
It's currently called only for global modules, but it probably can be changed.
If a module appears to be a perl/python module, modperl/modpython's OnModuleLoading will return HALT, and the other modules's OnModuleLoading won't be called. I don't think this HALT should be changed to HALTCORE to prevent situations when both modperl and modpython will load the module of the given name, loading 2 different modules under the same name.
SendModuleMessage("client_id", "getid " + remoteAddress); — maybe it makes sense to make the format more structured than a simple string? That's why such examples are useful, they show problems before implementation ;)
We already have a web-specific inter-module communication OnEmbeddedWebRequest (because of absence of the generic one), you can check how it's used for inspiration.
Inter-module communication is very needed since ages ago.
Too bad I can't comment directly on gist.
1. What's the point of version, and why it should be different from ZNC version?
2. `OnModuleLoading` had a somewhat different use case...
1. It's currently called only for global modules, but it probably can be changed.
2. If a module appears to be a perl/python module, modperl/modpython's `OnModuleLoading` will return `HALT`, and the other modules's `OnModuleLoading` won't be called. I don't think this `HALT` should be changed to `HALTCORE` to prevent situations when both modperl and modpython will load the module of the given name, loading 2 different modules under the same name.
3. `SendModuleMessage("client_id", "getid " + remoteAddress);` — maybe it makes sense to make the format more structured than a simple string? That's why such examples are useful, they show problems before implementation ;)
4. We already have a web-specific inter-module communication `OnEmbeddedWebRequest` (because of absence of the generic one), you can check how it's used for inspiration.
<!-- github-comment-id:50716473 -->
Q. What's the point of version, and why it should be different from ZNC version?
A. The idea at the time is in the event a module may receive updates more frequently than ZNC itself.
If *foo requires *bar (v2) yet *bar (v1) is installed, *foo should refuse to load if it requires a function in *bar (v2) that doesn't exist in *bar (v1).
Though, a way to require a minimum ZNC version may be something to consider as well, if a particular module requires something not in earlier versions.
Ben (MrC @ Freenode)
Q. What's the point of version, and why it should be different from ZNC version?
A. The idea at the time is in the event a module may receive updates more frequently than ZNC itself.
If *foo requires *bar (v2) yet *bar (v1) is installed, *foo should refuse to load if it requires a function in *bar (v2) that doesn't exist in *bar (v1).
Though, a way to require a minimum ZNC version may be something to consider as well, if a particular module requires something not in earlier versions.
Ben (MrC @ Freenode)
<!-- github-comment-id:50845693 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Was talking with @MrBenC in the channel when the subject of a possible inter-module communication and dependency system came up. He had an idea for what it could be useful for, as do I, as far as some use cases go.
The essential ideas are adding the ability for modules to define a version for themselves, depend or soft depend on other modules, and be able to exchange messages between them.
Rather than putting the result of a bit of back and forth in here, I've put it into a gist here to facilitate others modifying it.
Comments would be appreciated. Once a more concrete foundation is set, and the znc developers can agree on if it'd be a good idea or not, I (or someone else) could take a crack at making it a PR.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Inter-module communication is very needed since ages ago.
Too bad I can't comment directly on gist.
OnModuleLoadinghad a somewhat different use case...OnModuleLoadingwill returnHALT, and the other modules'sOnModuleLoadingwon't be called. I don't think thisHALTshould be changed toHALTCOREto prevent situations when both modperl and modpython will load the module of the given name, loading 2 different modules under the same name.SendModuleMessage("client_id", "getid " + remoteAddress);— maybe it makes sense to make the format more structured than a simple string? That's why such examples are useful, they show problems before implementation ;)OnEmbeddedWebRequest(because of absence of the generic one), you can check how it's used for inspiration.Q. What's the point of version, and why it should be different from ZNC version?
A. The idea at the time is in the event a module may receive updates more frequently than ZNC itself.
If *foo requires *bar (v2) yet *bar (v1) is installed, *foo should refuse to load if it requires a function in *bar (v2) that doesn't exist in *bar (v1).
Though, a way to require a minimum ZNC version may be something to consider as well, if a particular module requires something not in earlier versions.
Ben (MrC @ Freenode)