Data Sources - Refactor into Plugin system

[orbitusii]

DataSource should be an abstract or generic class that handles the connection process and maintenance DataSource will not do any of its own interpretation, but will feed into a subclass (maybe the target class of the Generic) that does the interpretation and allows for polymorphic, factory-built conversion from raw server data to a TrackDatum

LOKI should load plugin .dlls from ./Plugins/ at runtime using C# Reflection

[orbitusii]

Design change: data source should be an abstract class within the LOKI-BMS project proper. Implementation-level data source objects should be separate class libraries that get loaded at runtime using C#'s Reflection capabilities, allowing for simpler plug-and-play functionality for unique data sources.

Specific steps to take:

1. Extract DataSource's DCS interface into a separate project within the LOKI-BMS-csharp solution (likely called LOKI-DCS) 1.1. Other DataSource plugins will be named things like "LOKI-Falcon4," "LOKI-CVW5," etc.
2. The abstract DataSource class within the LOKI-BMS project and core library should have methods needed for all of its important behavior already defined 2.1. Plugin developers shouldn't handle the activation/deactivation logic, but will author specifics of connection, streaming, and parsing 2.2. Plugin developers should be able to add special Advanced settings for a data source class that can be tweaked in the Sources window and get serialized
3. LOKI-BMS will need to use C#'s Reflection features to load user plugins for DataSources in order to make the plugins work
4. Sources Window "ADD" button will need to be changed into a dropdown menu that works with a DataSourceFactory thing to build the specific DataSource a user specifies

[orbitusii]

Created loki-plugin-base subproject within the solution. Key classes and functions:

• LokiPlugin, abstract class that serves as the initializer and instance of the plugin
  • Detect() -> returns a PluginManifest struct that represents what the plugin provides and version data for compatibility
  • Init() -> performs plugin-level initialization
  • Reference to a Class (or Classes) within the plugin that does the interfacing with the data source so LOKI can create new instances of it when needed
  • References to custom window panes and classes defined in XAML or otherwise for controlling the plugin
• LokiDataSource, abstract class that gets derived into formal data sources, like DCS-GRPC
  • GetNewData() -> returns new TrackData structs for interpretation by the Database
  • Activate() and Deactivate() for controlling the source
  • CheckAlive() -> verifies that the source is active in the first place
• LokiPluginMenu, abstract class used to define plugin-specific menus and behavior that will be added to the main window
  • As these menus will be singletons within LOKI, plugins will have to manage their interaction with specific instances of the LokiDataSource class on their own

LOKI won't care about anything that goes on within the plugins besides these three classes. Plugins should reference loki-plugin-base and not loki-bms-csharp proper when being developed... unless they're specialized for deeper behavior within LOKI.

[orbitusii]

Functioning for now, needs some refinement and logic for custom menus implemented, but we'll get there eventually

[orbitusii]

Looks like Xaml content for LokiCustomMenu types will have to be loaded by the PluginLoader class in loki-bms-csharp proper. loki-bms-common does not have the required references and I can't find them, nor do I feel like it's strictly necessary to have that behavior implemented in common. Will work on that more tomorrow.

[orbitusii]

CustomMenu class can utilize TemplateWindow functionality, though that behavior will have to be implemented before it can be added to the plugins.