Feature #11367

Updated by Richard Neswold over 4 years ago

h2. Abstract

Erlang DPM's responsibilities are based upon CLIB-DPM's; handling readings and supporting redirection. Settings in CLIB may have shared some code with CLIB-DPM (database look-up, scaling routines, etc.) but the actual setting was done in the client's context. It has been suggested that the new DPM should handle settings.

h2. Pros

* Clients would only have to track the latest DPM protocol to gain readings and settings. If DPM doesn't support settings, is each client language needs to re-implement @SETDAT@/@SETS32@/whatever-follows.
* There has been talk about adding Channel Access to the bottom layer of DPM to support both ACNET and EPICs front-ends. If DPM handled settings, clients wouldn't have to know how to talk to multiple front-end architectures.
* DPM would forward settings to the setting service so clients wouldn't have to re-implement that code over and over.

h2. Cons

* -What What does it mean to run settings through a data pool? You can't merge requests.- Settings won't get merged. requests.
* -We're We're just adding one more hop to the setting's path.- The @SETS32@ header has an FTD field which can be used to schedule settings on an event, so the extra hop becomes irrelevant. path.
* DPM uses DRF2 strings to cleanly and succinctly describe a data acquisition request. DRF2 doesn't support the notion of settings. It would be nice if readings and settings had similar ways of describing the intent rather than having two unrelated APIs.

This topic needs more thorough discussion in a meeting.