Identify paradigm for service hierarchy

[acmcarther]

Modules are a sufficient abstraction for organizing services for now, but there is a huge degree of inherent structure in many of the services that we're not currently making good use of. One example:

Implicit relationship RawEventReader -> EventDelegator -> [EventHandlers]

Examples:

• WindowInput -> EventDistribution -> [Camera, Player]
• NetworkAdapter -> EventDistribution -> [Connection, HealthCheck, Snapshot]

This is only an example. There may be other emergent organizational strategies.

A codified organizational strategy might help reduce code and ease understanding.

[acmcarther]

One suggestion: Having services register themselves and their resources, and making those types private, would effectively make the resource private as well.

Very cool rust type trick that should enable better encapsulation.

[acmcarther]

Suggested design:

Have a module "Orchestration" that contains

• Priority level constants
• RegisterableModule

where RegisterableModule has a function "register" taking a mutable planner, and presumably registering services and data using the priority level constants in the common module. We'd like to prevent anyone from registering into the planner with their own priority values (to keep things centralized), so I'll probably do a typesystem trick.

Each service module should now define its ServiceModule, which is a dataless module implementing RegisterableModule. Then engine (and world) can be simplified to invoke register for each RegisterableModule. We could further subdivide this by having rust-level modules define sub-levels of RegisterableModule.

This comes from my exposure to Guice, which I agree has got some weaknesses. Thoughts @rschifflin?