Suggestion: Core-Modules

[entrhopi]

I'd like to discuss the idea of having a Blish internal directory core_modules that is shipped with Blish and contains current functionality (that would have to be separated from Blish core) and new upcoming modules. What comes to mind is Module Manager (part of Blish), Blish Updater (upcoming) and Home Tab (#303). That way Blish would only be the framework and everything else could be updated independently on a more regular basis.

[dlamkins]

Kind of an alternative look at this that we've recently discussed is splitting out a proper SDK. The EXE would essentially retain what you describe as the core modules and then an SDK with the actual module API would get split out.

Some of the module manager, etc. details would need to be part of that SDK which is why it may be difficult to split them out into their own modules (as modules would then have to build references to other modules which we've made possible, but is certainly a bit more work).

@Archomeda in case you had further thoughts. 🤔

[Archomeda]

Ah yes, this all comes down to how far you'll want to take it. There's some pros and cons here. For example, distributing separate "core" modules will make them easier to update independently as already mentioned. However, I think that - at this moment - it will make it harder to maintain with how Blish is a monolithic system at the core.

Some of my thoughts:

In my opinion, the concept behind the SDK is that it should only have the functionality to bridge modules to Blish and vice versa (and ideally make it as easy as possible to develop against). Of course, this doesn't mean that there can't be any core modules at all. I would view them them as default provided modules in order to have a good first user experience. People can turn them off if they want to. Basically, this means that core modules can communicate with Blish HUD via the SDK as well, and that there's no technical difference between a core module and a normal module.

What should be regarded as Blish HUD functionality, and what is a core module? That's up to you. However, I think that the module manager and updater really are a part of Blish itself, and you might make it yourself only more difficult if you make that into a core module (e.g. how are you going to bridge module management between Blish HUD and the module itself?). I do see the home tab being a core module (or have the home tab integrated in Blish itself, and add home tab widget support via the SDK or something).

If you would split up the core Blish HUD functionality into separate projects, while they actually are still hard-referenced to each other, it may just make Blish HUD too complex for a (very) small team behind it.

That said, this ended up a bit longer than I had thought it would be and I may have drifted away from the original idea 😅. My idea of core modules is something that isn't entirely new (hello pathing). So if I'm completely misunderstanding the concept of core modules, feel free to correct me here!