Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
Different facets of behaviour for either talking about a device or for interacting with a device are modeled as derivatives of Behaviour and HandlerBehaviour interfaces, respectively. The reason for differentiating between the two lies in the slightly different context required. Base implementations of these abstractions are provided as AbstractBehaviour and AbstractHandlerBehaviour by the driver subsystem. It is the implementation of these abstractions where the device and protocol-specific code resides.
The rough guidelines for modeling use a Goldilocks principle. The behaviours should be defined as not to be to broad in that they should not span multiple topics, nor should they be too narrow where they implement a specific bit of a topic. The driver service provides means for apps to see if a device supports a particular behaviour and the agreement is such that the device either supports the entire behaviour or it does not support it. This is to limit the complexity of apps and to make the programming model easier. Properly scoped behaviour abstractions work towards that end.
Contexts
DriverData is a container for data learned about a device in prior interactions. It
...
Similarly, DriverHandler is a context for interacting with a device.
provides
Behavioursfor interacting with a devicehas
DriverDatahas parent
Driver
...