Orion Internal Architecture Proposal

[tylerjwatson]

Rationale

Orion at the moment seems to be largely a copy-paste of TShock's design patterns. Not to discredit the design as you have to start somewhere, thinking about the architecture I would really like to initiate the change to a modular design.

It's vital that chunks of Orion be self-contained, as they may be swapped out for anything else.

Structure

I propose that modules in Orion be self-contained classes inheriting from an abstract OrionModuleBase class which essentially just defines a single Run() method which the core will call to run it. OrionModuleBase implements IDisposable, and the module must be responsible for destroying its own functionality, and the server must be able to run without it enabled; it just misses that functionality:

• Modules can now even live in separate assemblies
• Modules are interfaces, whose implementations may be swapped out at any point and everything goes on its merry way
  • On this, as long as the interfaces don't change, APIVersion tags will need to be ticked less and everyone will be happy
• Module sets up its own hooks, everything it needs to survive and function as expected
• Module tears down its its own hooks and everything it needed to function
• Modules may interact with other modules by Orion's core.Get<TModule>() method which will return the instance of module for that type, beware of nulls.

  Initialization

  1. Modules should be collected by Orion which are marked with the [OrionModule("ModuleName", "Author", {order})] attribute, and instantiated when it runs.
  2. Orion initializes all modules by the author, and calls the abstract OrionModuleBase.Run() method
  3. Programs then brings the awesome

[tylerjwatson]

Intials

• ICommandProvider - provides support for commands
• IAuthenticationProvider - provides user, IP, UUIDs to TShock
• IBanProvider - provides bans via various mechanisms (ban tables, blcoklists, CIDR)
• ISSCProvider - provides inventory data for SSC enabled characters

[QuiCM]

+1. If you haven't started on this, I'll begin sometime this afternoon

[Ijwu]

Sounds like an internal plugin system. Why not simply export all this functionality into plugins to begin with? How similar do we get to having (what is essentially) a plugin system before just overhauling the current plugin system?

Couldn't we just implement all this functionality in plugins using the current plugin system? We could patch in a core.Get<TOrionPlugin>() method.

It just sounds like a huge overlap in functionality.

[tylerjwatson]

they aren't entire self-contained plugins, they are small self-contained modules that make up a framework, it's possible for external plugins to register their own modules, unless I am not following what you mean.

@WhiteXZ I reckon start by defining the interfaces, that way we have a concrete design on what implementaions must provide to the core

[Ijwu]

I just mean that it's almost too similar to simply having a plugin system. There's a huge overlap in functionality and it sounds suspiciously "wet".

Both of these things implement some interface and are expected to have a specific attribute. They are both responsible for their own run-time, initialization, and de-initialization. They are loaded at run-time by Orion, which looks for that specific attribute. It's setting off some "not DRY" alarms in my head.

The only difference that I can tell is simply that modules are developed internally as plugins are third-party. If this is the case then we might as well use a single system for loading both third-party and internally developed modules.

This module system idea could simply replace the plugin system in its current form. It seems as though this could be more robust anyway.

[QuiCM]

I can replace OrionPlugin with OrionModule and we can design for a modular system if so desired

[tylerjwatson]

I'm confused, are you saying we do away with TSAPI plugins and move to orion modules?

[tylerjwatson]

I'm basically proposing what you need to do to acheive object-oriented modular design, this has nothing to do with plugins.

[Ijwu]

The misunderstanding between @tylerjwatson and I has been sorted since and we're working on the module system as described here and in other issues.

[tylerjwatson]

This is quite out of date. I am closing this in favour of another proposal coming very shortly.