The application that triggered issue #572 uses a ruleset named io.picolabs.pds (which is how it avoids the use of entity variables).
This is another, indirect way in which a pico can maintain state.
When a ruleset uses entity variables, these are only available to code running on the same pico and in the same ruleset.
Having a ruleset like io.picolabs.pds makes it so that all rulesets running in the pico can share state (they must use module io.picolabs.pds alias pds in order to do so).
The API provided by io.picolabs.pds consists of the function getData, the rule setData (selected by the event pds:new_data_available), and the raised event pds:data_added. All of these expect parameters/attributes named domain and key and value (the latter returned by the function).
This idea is a simplification of the PDS used as a "profile" in FUSE.
The application that triggered issue #572 uses a ruleset named
io.picolabs.pds(which is how it avoids the use of entity variables).This is another, indirect way in which a pico can maintain state.
When a ruleset uses entity variables, these are only available to code running on the same pico and in the same ruleset.
Having a ruleset like
io.picolabs.pdsmakes it so that all rulesets running in the pico can share state (they mustuse module io.picolabs.pds alias pdsin order to do so).The API provided by
io.picolabs.pdsconsists of the functiongetData, the rulesetData(selected by the eventpds:new_data_available), and the raised eventpds:data_added. All of these expect parameters/attributes nameddomainandkeyandvalue(the latter returned by the function).This idea is a simplification of the PDS used as a "profile" in FUSE.