Prepare a presentation on Orion API

[tylerjwatson]

This issue is to track a presentation to other stakeholders what orion actually is, and to go through an end-to-end use case for why some of Orion's design decisions are the way they are, and to discuss the merits between them

Outcomes of the presentation:

1. A clear consensus on what Orion actually is, and what it means for Terraria (OTAPI)
2. A clear consensus on what Orion is not
3. A clear consensus on the development strategy for Orion so far (TDD)
4. A clear consensus on what terraria features mean and how they map to Orion services

Once the above has been achieved, it's then possible to document it out.

Materials:

• A layer-diagram illustrating where Orion fits between Terraria and server modules (for point 1)

Notes:

• Orion is an abstraction layer with the goal of hiding as much of Terraria's internal mechanisms away from server/software engineers as possible.
• Orion makes the "only worry about what you can control" mantra possible:
  • Remove the need to interact with the Terraria statics
  • Remove the need to tick API versions as Orion takes care of the binary changes in Terraria
  • Provide Terraria features in an abstracted implementation
  • Goal is for server owners to not worry about low-level Terraria mechanisms
• Orion is also a container, in that it is responsible for running and managing instances of the Terraria server
  • Orion itself is a class library, but has front-end projects which bootstrap it (Console, Windows Services etc)

Orion Architecture:

• Orion is built with the inversion-of-control principle:
  • Only worry about what you need to know in the API; don't worry about the rest of it or how it's implemented
  • Don't worry about dependencies, just inject them
  • Everything is interfaced; don't worry about the implementations

More to come as I think of them

[kevzhao2]

Closing as this is not relevant atm. If necessary, open a new issue for this.