Enable pykiso for more complex connector interfaces #211
Locked
sebastianpfischer
announced in
Technical decisions ahead
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Problem Description
In the pykiso philosophy, the auxiliaries were supposed to contain the "logic" and the connector was supposed to be the "transport" for any needed communication from the auxiliary.
When we needed to work with BLE, we tried to have on one side 2 specific auxiliaries running on top of a ble-connector.
The tradeoff made was that the BLE configuration is more static and cannot be changed easily after configuration.
Unfortunately for us, some additional needs to enable for more complex BLE scenarios occurred which created a refactoring activity.
Now we see more and more cases where when a complex protocol (like BLE) is used, we need to create a more complex connector.
Goal
We want to define a mechanism to enable the creation of such connectors without ending into a certain level of Anarchie that may hurt us in long term.
We want to execute different functionalities on the connector (if the connector is capable) besides send() and receive()
Technical context?
Influencing Factors
Assumptions
None
Alternatives
Option 1: additional connector interface with commands descriptions
Graph
Additional elements
Issues
(to analyse)
How to ensure that we retrieve the right answer to a command sent by the aux and processed by the connector?
How to ensure we do not block the connector too long while processing the command? (the aux will hang on the next command or send while the connector is processing)
Option 1.1: replace the invoke with a decorator and cmds with lexicon
Graph
Additional elements
Issues
Option 1.2: token and timeouts
Graph
Additional elements
Issues
Option 2: forward physical channel API (minimal implementation effort)
Code
aux1.channel.cc_send("data") -> aux1.cc_proxy.cc_send("data")
aux1.channel.remote_id = 123 -> aux1.cc_proxy.proxy_aux.channel.remote_id = 123
Additional elements
Reasons:
Issues
What should be done when the user needs an attribute of the physical channel that is already implemented by the proxy channel?
To be analysed for more complex physical channel APIs
Option 2.1: forward physical channel API with interface declaration for connectors
Code
aux1.channel.cc_send("data") -> aux1.cc_proxy.cc_send("data")
aux1.channel.remote_id = 123 -> aux1.cc_proxy.proxy_aux.channel.remote_id = 123
but also:
Additional elements
Reasons:
Remove drawbacks of option 2.
Issues
Decision Matrix
Final Decision
Alternative 2.1 shall be adopted as a first step of hiding the proxy creation and manipulation from the user.
Beta Was this translation helpful? Give feedback.
All reactions