Tree layout and assembly restructure to align with packaging

[david-c-kline]

Overview

Currently, there are four top level folders in our tree (beneath Assets):

• MixedRealityToolkit
• MixedRealityToolkit-SDK
• MixedRealityToolkit-Examples
• MixedRealityToolkit-Tests

This proposal defines adding the following to for easy package source discovery:

• MixedRealityToolkit.Devices
  • WindowsMixedReality
  • OpenVR
  • UnityInput
  • WindowsVoiceInput
• MixedRealityToolkit.Services
  • BoundarySystem
  • DiagnosticsSystem
  • InputSystem
  • SpatialAwarenessSystem
  • TeleportSystem

As part of this change, assembly definitions will be adjusted to conform to the following convention:

MixedReality.Toolkit. < Layer > . [ Area ]

Examples:

• MixedReality.Toolkit.Core (was MixedRealityToolkit)
• MixedReality.Toolkit,Devices.WindowsMixedReality
• MixedReality.Toolkit.Services.BoundarySystem

Future pull requests will address renaming existing top level folders (ex: MixedRealityToolkit-SDK -> MixedRealityToolkit.SDK).

Acceptance Criteria

• Assemblies reference the minimal set required to function (ex: most will only reference MixedRealityToolkit.Core)
• Samples and demos updated to reference new assemblies and namespace changes,
• New assemblies created
  • MixedRealityToolkit.Services.*
    • BoundarySystem
    • DiagnosticsSystem
    • InputSystem
    • SpatialAwarenessSystem
    • TeleportSystem
  • MixedRealityToolkit.Providers.*
    • UnityInput - To be addressed in a later change (needs vNEXT Task: Refactor Controller Mapping Profile to accept individual controller scriptable objects. #3074)
    • WindowsVoiceInput
    • WindowsMixedReality - To be addressed in a later change (needs vNEXT Task: Refactor Controller Mapping Profile to accept individual controller scriptable objects. #3074)
    • OpenVR - To be addressed in a later change (needs vNEXT Task: Refactor Controller Mapping Profile to accept individual controller scriptable objects. #3074)

[SimonDarksideJ]

In stead of

MixedRealityToolkit.Devices

Better

MixedRealityToolkit.Providers

As there could be many different data providers being added to the toolkit, e.g. Azure Speech, Networking, etc

Overall I'm not opposed to this change as it doesn't really change anything in code. However, I will point out it makes no difference in packaging. When packaging, you simply select the files from source you need and package them up in to a simple deliverable. In other projects, this is either done with NuGet or other packaging configuration tool. Simply breaking up / moving the folders only really helps visually.

[david-c-kline]

I will point out it makes no difference in packaging.

I agree, it is definitely possible to package regardless of tree structure. The intent is 100% to make it clearer and easier to understand our component divisions.

[david-c-kline]

Edited description to fix grammar error and to be a bit more descriptive.

[david-c-kline]

In stead of

Providers is a reasonable name. I'm cool adopting that instead of devices. As a side effect, i would likely rename the current devices folder / namespace to match the providers replacement.

[jwittner]

Can we drop the word System from everything? Seems like everything in a Service is a System.

[david-c-kline]

Can we drop the word System from everything? Seems like everything in a Service is a System.

We could definitely do that. I will address when I rename "Devices" to "DataProviders" per @SimonDarksideJ's feedback

[StephenHodgson]

No, systems are "Singletons". While all systems are services, not all services are systems.

[david-c-kline]

While all systems are services, not all services are systems.

Is there an example of a non-system service that would warrant it's own assembly in the MRTK today? I can see the class / interface being called *System, but the namespace / assembly could drop the moniker