[Discussion] Instantiate another instance of the MWDI as HMDI (HistoricalMicrowaveDeviceInventory)

[kmohr-soprasteria]

Originally, the idea was to have the MWDI and the HMDI as follows:

• the MWDI obtains its data from the Controller, if a device is no longer connected it is deleted from the cache
• the HMDI would have obtained its data from the MWDI (as to not put additional load on the Controller and Mediators), if a device would not be connected any longer, data would still be kept for a configurable amount of time (retention period).

The MWDI and HMDI in general would work nearly in the same way, but still the original idea was to have two separate specifications. A better approach would be to have just one specification which allows the MWDI also to be instantiated with HMDI functionality.

---

Some adjustments to consider:

• include a profileInstance to configure retention periods: only relevant for the HMDI instance
  • this also requires information to be stored upon when the last CC update was done (this information would also be interesting later on for other applications)
• HMDI can subscribe to the MWDI instead of the Controller, to get information about new CC updates
  • need to check, if additional forwardings would be required (e.g. one set to be used for the MWDI, another set to be used for HMDI) or if existing forwardings could be modified (e.g. change target application)
• also need to consider/check:
  • usage of live-paths: HMDI would only have cache paths and would NOT offer live paths
  • theoretically, they could be kept and when they are called, the latest CC from the MWDI is fetched. But the naming with "live" might be misleading.
  • or paths could be build with a stringProfile, e.g.:

    now:              "/core-model-1-4:network-control-domain=live/control-construct=..."
    possible change:  "/core-model-1-4:network-control-domain={A_STRING_PROFILE}/control-construct=..."