Re: CA Provider for PVXS

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

Hello Nick,

On 6/8/26 8:35 AM, Marks, Nicholas via Tech-talk wrote:

Hello,

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");).

I was not enthused about supporting the (imo.) hacky code behind CA ClientProvider.  Wrapping libca adds the problem of API impedance mismatch to the differences between the two protocols.  I do not see a similar wrapper appearing in PVXS.  I would not rule out including a new CA implementation, with a similar API, but this is not at all a priority for me.

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.

To my mind, dual protocol servers are the way to go.  I think the server side is better equipped to handle the differences between the two protocols.  Including QSRV2 in all IOCs provides a ~95% solution.

If "transparent" support for PVA/CA is critical for your client application, and "pvac::ClientProvider" + CAProvider works for you, then great.  "pvac::" was my last attempt to wrap a not-horrible API around pvAccessCPP.  Like much of the original pvDataCPP stack, it is in deep maintenance mode at this point.  Still, the EPICS community has a history of keeping such code ~viable for a very long time.  I doubt that obsolescence will force a migration on you anytime soon.