DRF should allow users to not only read the setting property but to pass a value to the setting to make a change.
#1 Updated by Richard Neswold almost 2 years ago
Several of us had informal discussions that setting support shouldn't be part of DPM. In the past, the console DPM didn't making settings. Somehow we've attached this feature onto DPM. Moving settings into a separate service has the following benefits:
- DPM can focus on supporting all the ways we can read data
- Accelerator data from ACNET front-ends and IOCs
- Save/Restore data
- Data logger data
- FTP and snapshot data
- Setting service can focus on handing settings
- Protocol can be tailored to setting requirements (instead of shoe-horning it into the DPM protocol)
- Validating credentials of the request
- Writing successful settings to the setting database
- Handling knobbed settings
This codebase may actually run in the same VM as the DPM, but I'd recommend is not be part of the DPM package. It would be is own package and would connect to ACNET through its own handle.