ryan-summers
commented
2 years ago I initially started implementing a proof-of-concept, but hit some implementation issues and began to think whether or not we want to support this kind of API directly in Miniconf.
For Booster, we have the following needs:
- Process channel state changes (that may or may not fail, takes time to transition)
- Handle RF channel bias modification
- Process a request to save settings to non-volatile memory
(1) takes up to 500ms in worst case conditions. Additionally (1) can fail - e.g. the user requested a channel to be enabled, but the channel interlock tripped during the enable process. This could likely be handled directly by the changes in #63.
For (2), we currently implement the tuning algorithm in software. E.g. you modify bias voltage and booster tells you the resulting drain current. Software then iteratively tunes the voltage to a desired drain current. This would require providing data in the Miniconf configuration acknowledgement.
(3) isn't a setting at all. This would be better served by just subscribing to some cmd/<prefix>/save topic and managing that out-of-band of Miniconf.
Exposing single-shot events with miniconf currently looks like:
truefalse->truechange, act on it, records that it has acted on itfalsebefore making any other miniconf changeThis has a couple of downsides:
The potential enhancement is to implement a specific miniconf endpoint that supports request-response patterns. A hot incoming request would be stored by miniconf until executed and cleared by the application, at which point the corresponding hot response is stored by the application, and serialized/sent/cleared by miniconf. The data structure looks like a pair of single-entry queues, one for request, the other for responses. There is likely an implementation already. It would be useful to be able to split it into miniconf and application halves to make it lock-free.
Open questions: