Refactoring?

[mark-i-m]

One of the cool ideas brought up (by @md678685) was making the code more modular.

I think this would really make our lives a lot easier, and hopefully encourage people to hack on different parts... I see two options:

1. Make a different repo for each component. The core repo would contain the restarting/updating code. There would also be a separate repo with shared code/libraries (such as github api stuff). Then, all of the other subsystems can live in their own repo. Upside: Cleaner organization and enforces modularity of components. Downside: More complex to manage starting/stopping components and coordinating PRs with multi-component parts might require some engineering (which I think might be solved by a issue command such as @chaosbot depends on #Chaosthebot/Chaos#600 or something).

2. Use a strict well-designed directory/module hierarchy and enforce by conventions. (I personally lean here)

[Redmega]

I lean 2 as well. Multiple repos would be super interesting but might prove to be complicated to orchestrate. I'm interested in others thoughts on this.

[mpnordland]

My idea is that we break the code into plugins (Some options for how we do that are here: http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html). The idea being that plugins are sandboxed so that if an error occurs and a plugin crashes, it won't kill the core code, and could possibly be immediately restarted.

[Redmega]

That's assuming all the modules will be in python though. I'd be interested in making a node module.

Maybe we can have different central language hubs which connect to a central controller.

[mpnordland]

Well, we could, it would in fact make the separation more pronounced, we'd need a central core that would spawn child processes and some kind of ipc.

[Swizz]

And how about multi modules living into the same repository ?

[mdcfe]

I don't think I was the first to suggest modularity :p

I was thinking that the "core" would be the "central controller", as suggested by @Redmega, and would launch components either as child processes or daemons and have a common protocol to interact with it from modules (perhaps through a Unix/TCP socket), as suggested by @mpnordland.

Each component would be in a separate repo, and would contain a metadata file with information about how they should be launched. Repos could become recognised as components to launch by through a config for the core, and if new components are added, a PR is submitted to add them.

Shared libraries could be independent repos which are referenced by submodules, which would ease synchronising the libraries between repos and should still allow for some components to stay on older versions of shared libraries if breaking changes are introduced through library updates until the component itself is updated.

I don't think multiple separate modules should live in the same repository - the separation of modules is what will help identify separate modules.

[mdcfe]

@mark-i-m Any particular reason for closing?

[mark-i-m]

I didn't realize there was active work still going on, as the repo has been silent for a while TMK... Reopening

[mdcfe]

I mean, it's more that if some work does happen then this will be much easier to find.

[mark-i-m]

I would like to close this PR to clean up my dashboard. Does anyone have objections?

[Redmega]

Go for it. Work has left me not able to contribute to Chaos anymore.

[mdcfe]

No objection here.