|
I think the disagreement is not on what should be forwarded, but on how it should be presented.
From the data perspective, all of them usually provide what you mentioned (value, timestamp, type, units, etc), content-wise, but with slightly different formats depending on how one thinks data consumption gets easier.
A clear example already showed up in the prior emails:
-
Newly divulged SLAC's
pvua returns a
pyepics-like structure regardless of provider. Makes sense for the use case mentioned on their email
-
-
The first two include only CA and PVA. For the cases like PVWS or the Java clients, that may support MQTT/Tango/others, it may get even harder to agree on "one standard to rule them all", despite the contents being kind of the same.
Cheers,
André Favoto
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Dmitry Yu. Bolkhovityanov via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, June 10, 2026 07:10
To: Kasemir, Kay <kasemirk at ornl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS
Hi Kay,
On Mon, 8 Jun 2026, Kasemir, Kay via Tech-talk wrote:
> The hard part is of course that you can never get 2 people to agree on what such a ?PV?, the common denominator of all protocols, should look like.
Is there really much disagreement?
A "PV" usually consists of:
1. The data itself (with type descriptor - int/float/..., # of elements).
2. A timestamp.
3. A "status" of some kind (STAT+SEVR, quality, a bitmask of errors, ...).
Or are you talking about API? That is usually "read, write, monitor".
Even TANGO, with its messy DeviceAttribute (whose internals violate most
"good design practices") is compatible (and pairable) with EPICS.
With best regards,
Dmitry
|