Mixedrealitytoolkit-unity: Feature Request: Profiles define the service implementations that will consume them

[Railboy]

Describe the problem

At the moment service implementations are specified in the MixedRealityToolkitConfigurationProfile. Implementations are configured via the profile object associated with the service's interface type.

This pattern assumes that any class implementing the service interface can be sufficiently configured by the generic profile type associated with that interface.

Eg, any implementation IMixedRealityBoundarySystem will never need config data beyond what's available in a MixedRealityBoundaryVisualizationProfile object.

In practice different service implementations often have wildly different configuration needs, even if they conform to the service interface.

This calls for different profile classes for certain service implementations. But we lack a mechanism to enforce the correct pairing of service implementation with profile class, so that's not an option.

Describe the solution you'd like

The service implementation should be defined in the _service profile_, not in the base configuration profile.

Available service types should be constrained according to a base type provided by the profile class (probably via an attribute). Any service of / extending that base class will be a permitted option.

This approach wouldn't change how services are consumed by the toolkit. All service implementations will still be expected to conform to the service interface. It would only create an enforceable link between profile and service implementation.

Describe alternatives you've considered

Disable all constraints on profile types in the inspector, then leave it up to each service implementation to detect when they're being fed a profile type they can't use. Request that developers throw descriptive errors in this case.

@radicalad Hoping you can provide one or two concrete examples of this problem.

[StephenHodgson]

Only problem with this is that not every service requires or needs a profile (although the core services do have that requirement)

[Railboy]

A bare-bones profile could consist of nothing but a SystemType field defining its implementation type.

Or we could just not require profiles for data providers / extension services, since there's an expectation that any profiles they might use would be one-offs anyway.

[radicalad]

The issues I'm running into concerns platform specific implementations that have conceptual crossover, but the profile implementations don't. For example, a SpatialAwarenessPlaneFinding profile for iOS will look drastically different than one for Android. Relying on purely the IPlaneFinding interface as a check will still result in a broken experience.

[davidkline-ms]

We (@keveleigh and I) have had similar discussions in the recent past. we should get together, share thoughts and update the proposal.

[davidkline-ms]

the primary guide should be the end-developer customer. we need to balance ease of use, ease of understanding, etc