You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the multiplexed settings only have a single storage of all the active settings.
As detailed in #99 (review), a new "staging" API could allow staging settings with a commit token (e.g. a std::string) such that they are first stored in a background "staging" collection, instead of in the active settings collection.
Then later on, the staged settings can be transported to the actually active collection of the ctx_settings via multiple ways:
It could be activated explicitly through the settings API by passing the unique commit token
Implicit activation via a tag_t on one of the streaming ports
Implicit activation via a pmt_t message on one of the message ports
Some things to consider:
Before staging the settings, they should be validated, i.e. check if the keys actually map to existing struct member fields in the node and check for correct types and potential Range constraints (e.g. a field might want to only accept positive integers)
Instead of using just a simple string as a commit token, we potentially might want to generate a unique hash - in a git-like fashion
The text was updated successfully, but these errors were encountered:
Right now the multiplexed settings only have a single storage of all the active settings.
As detailed in #99 (review), a new "staging" API could allow staging settings with a commit token (e.g. a
std::string
) such that they are first stored in a background "staging" collection, instead of in the active settings collection.Then later on, the staged settings can be transported to the actually active collection of the
ctx_settings
via multiple ways:tag_t
on one of the streaming portspmt_t
message on one of the message portsSome things to consider:
The text was updated successfully, but these errors were encountered: