Inter-module communication, dependency, versioning proposal #367

Open
opened 2026-10-05 04:15:49 +02:00 by adam · 2 comments
Owner

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.

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 -->
Author
Owner

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.
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 -->
Author
Owner

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 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#367