openiiot / openiiot.core Goto Github PK

Presently the Configuration model is as follows:

Dictionary<Type, List<object>>

The dictionary is keyed by asset type (something that implements IConfigurable<T>) and the value is a list of objects whose Type corresponds to the generic Type parameter of the IConfigurable interface.

Initially the intent was to allow binaries of a configurable type to be loaded and for the Plugin manager to create multiple instances of those Types, each with it's own configuration model.

In practice any use case requiring multiple instances can be covered within a single instance of the configurable type. The only benefit to having the Plugin manager manage this is that any threading would then be handled by the core instead of the plugin having to do it.

Consider whether to use reflection to determine whether Types are configurable instead of using explicit registration. This would eliminate ConfigurableTypeRegistry and registration code in the ConfigurationManager and downstream types

Presently the ConfigurationManager stores strongly typed configuration models in the configuration file. Should a downstream asset update its model, the ConfigurationManager needs a way to migrate the previous configuration to the new model.

Initial thoughts are to implement a ConfigurationMigration/IConfigurationMigration to be used with the Discoverer. Implementations could have [ToVersion] and [FromVersion] attributes, allowing the ConfigurationManager to determine which migration to apply.

Migrations should be additive in that an upgrade from 1.0 to 3.0 should apply migrations for 1.0 -> 2.0, then from 2.0 -> 3.0. A migration setup for this scenario might look like the following:

[FromVersion(1.0.0.0)]
[ToVersion(2.0.0.0)]
public Migration1to2 : IConfigurationMigration { }

[FromVersion(2.0.0.0)]
[ToVersion(3.0.0.0)]
public Migration2to3 : IConfigurationMigration { }

The ConfigurationManager would need to collect all migrations and examine the versioning attributes to ensure an upgrade path is available. After migration is complete the deprecated configuration would be removed from the config (and probably backed up somewhere).

For API consistency methods operating on resources should, unless named Find___(), accept parameters of the same resource type. Accepting locators such as name or fqn is redundant as the API generally provides a Find method.