I've always found that splitting an app into separate logical components keeps things simpler and manageable in the long run. So that's what this does.
Keep the core package as simplistic and tight as possible. The very basic for a BNC to run.
Introduce an app-wide message bus that other components can tap into.
Components can be added for the extra functionality. The functionality may be part of the core project, but it is still an addition on top of the very core BNC function.
The code for the components does not interfere with the core BNC function.
The same pattern can be used for runtime loadable modules using the same event bus, but that needs extra thinking about with the module scope and unloading events. We can deal with that later on.
What is a component
A component is its own package, which can be built up individually from the core BNC functionality
Listens for events from the message bus.
Can be tested individually by manually triggering events.
What components are not
Components are not runtime loadable modules. This is functionality in the main project that are logically separated from the core BNC functionality.
If a module is commented out at compile time, other functionality of the project will not be impacted. The functionality of that component will only be unavailable.
Foo
This PR is only an example - there is more work to be done to make this generally usable
More events need to be added.
Making sure any important core parts are accessible from the manager.
Any common event properties should be abstracted away for consistency (ie. halt).
Typing up events is currently tedious. Work on that project needs to be done.
Using interface{} for everything is generally a bad idea for dev purposes and performance. Look into using event structs instead.
This example
This PR example shows the general idea in action, by implementing a *goshu nick to control the users BNC. Similar to *status of ZNC. Once the events are in place in the core project, you can see just how independent the *goshu code can be without impacting anything else.
General idea
I've always found that splitting an app into separate logical components keeps things simpler and manageable in the long run. So that's what this does.
What is a component
What components are not
Foo
This PR is only an example - there is more work to be done to make this generally usable
manager
.halt
).This example
This PR example shows the general idea in action, by implementing a
*goshu
nick to control the users BNC. Similar to*status
of ZNC. Once the events are in place in the core project, you can see just how independent the *goshu code can be without impacting anything else.