Updated Essentials Architecture (markdown)

hvolmer
2020-02-11 19:15:29 -07:00
parent 8ffae545e1
commit 9ac5b121b9

@@ -39,11 +39,11 @@ Types of devices:
A Device doesn't always represent a physical piece of hardware, but rather a logical construct that "does something" and is used by one or more other devices in the running program. For example, we create a room device, and its corresponding Fusion device, and that room has a Cisco codec device, with an attached SSh client device. All of these lie in a flat collection in the `DeviceManager`.
> The `DeviceManager` is nothing more than a modified collection of things, and technically those things don't have to be Devices, but must at least implement the `IKeyed` interface (simply so items can be looked up by their key.) Items in the `DeviceManager` that are Devices are run through additional steps of [activation](a) at startup. This collection of devices is all interrelated by their string keys.
> The `DeviceManager` is nothing more than a modified collection of things, and technically those things don't have to be Devices, but must at least implement the `IKeyed` interface (simply so items can be looked up by their key.) Items in the `DeviceManager` that are Devices are run through additional steps of [activation](https://github.com/PepperDash/Essentials/wiki/Construction-and-Activation-phases-concepts#2-pre-activation) at startup. This collection of devices is all interrelated by their string keys.
In this flat design, we spin up devices, and then introduce them to their coworkers and bosses, and get them all operating together to form a running unit. For example: A room configuration will contain a "VideoCodecKey" property and a "DefaultDisplayKey" property. The DeviceManager provides the room with the codec or displays having the appropriate keys. What the room does with those is dependent on its coding.
In this flat design, we spin up devices, and then introduce them to their "coworkers and bosses" - the other devices and logical units that they will interact with - and get them all operating together to form a running unit. For example: A room configuration will contain a "VideoCodecKey" property and a "DefaultDisplayKey" property. The `DeviceManager` provides the room with the codec or displays having the appropriate keys. What the room does with those is dependent on its coding.
> In the default Essentials routing scheme, the DeviceManager is asked for the various devices defined in the desired route, and then queried for the devices that may exist in the tie lines defining the route. This is all done at runtime, on the fly, using only keys, and as soon as the routing operation is done, the whole process is released from memory. This is extremely-loose coupling between objects.
> In the default Essentials routing scheme, the routing system gets the various devices involved in given route from `DeviceManager`, as they are discovered along the defined tie-lines. This is all done at route-time, on the fly, using only device and port keys. As soon as the routing operation is done, the whole process is released from memory. This is extremely-loose coupling between objects.
This flat structure ensures that every device in a system exists in one place and may be shared and reused with relative ease. There is no hierarchy.