Re: CA Provider for PVXS

["Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>]

Hi:

For what it’s worth, look at the EPICS Java ecosystem.

PVAccess is good at what it does, so is CA, and they’re different.

A dedicated PVA library is perfect, having it somehow also handle CA just complicates matters when it’s hard enough to maintain the library for one protocol.

But yes, many clients don’t need all the detail offered by the dedicated PVA or CA libs.

They just need a “PV” with value, timestamp, alarm state, display hints.

In the java world, we have a core-pv layer with implementations for PVA, CA, MQTT, Tango, local variables, simulated variables, even site-specific protocols. You can get a PV with value, timestamp, alarm state, (some) display hints from any of the protocols that way. It’s sufficient for client tools like display managers, save/restore, alarm handlers, archives, beamline automation. It cannot​ get you the “cainfo” detail about CA server port, neither does it support PVA RPC operations or arbitrary PVA structures beyond the normative types. For lower-level CA or PVA details you do need to use the specific libs. But for 98.5% of your use cases, it’s one API regardless of protocol.

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. On the java side I think it helped to not just propose a PV layer which then nobody uses, but provide the PV layer from the onset with a generally useful tool like CS-Studio.

On the C++ side, you’d have to create a PV layer in one of the broadly used tools, which might then entice others to use that same C++ PV layer.

---

I was curious if there has been any discussion in the community about implementing a Channel Access provider for PVXS? I think most would agree the PVXS API is much easier to work with than the pvAccessCPP API, however one thing pvAccessCPP has over PVXS is it also provides a CA provider(epics::pvAccess::ca::CAClientFactory::start(); pvac::ClientProvider provider("ca");).

Any new client applications will likely need to support both CA and PVA (except maybe for some very new sites which are trying PVA only) so it is especially useful to have a single API for the EPICS communication layer of such an application. The way I see it, a C++ EPICS client which is to support both CA and PVA will need to use PVXS for PVA and the C API for Channel Access or alternatively stick with pvAccessCPP. This isn't the end of the world, but it sure would be nice to use PVXS for both protocols. I'm interested to hear others' thoughts on this.