Re: CA Provider for PVXS

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

Thanks everyone for the helpful notes! Good we have a tech-talk thread about this now as I imagine it will continue to be a common question for newcomers writing clients. I tried mocking up a simple client and I'd agree the one library per protocol approach seems to work well. For a simple client along the lines of what Kay mentioned (just needing a “PV” with value, timestamp, etc) using both CA and PVXS together only takes a couple hundred lines of code per protocol, so this is probably the simplest approach.

Take care,

Nick

---

From: André Favoto <andrefavotto at outlook.com>
Sent: Monday, June 8, 2026 3:08 PM
To: Marks, Nicholas <nmarks at anl.gov>; Michael Davidsaver <mdavidsaver at gmail.com>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS

 

You don't often get email from andrefavotto at outlook.com. Learn why this is important

I went though this exact same chain of thought when starting WEISS ~1 year ago, and I believe most people starting new clients also do. To share a bit of my endeavor: I started by using pvaPy, as it does support PVA and CA within the same library. 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

I went though this exact same chain of thought when starting WEISS ~1 year ago, and I believe most people starting new clients also do. To share a bit of my endeavor:

I started by using pvaPy, as it does support PVA and CA within the same library. However, with the goal of using PVXS, I wanted to use p4p. I opened this issue on p4p due to the existence of the "provider" parameter, which could lead one to believe other providers were to be supported at some point (thanks Michael for the prompt response🙂). As already suggested and I later agreed as the best solution, I ended up migrating to a dual-protocol backend.

I still wanted a transparent interface for the frontend, to simplify the TypeScript data layer. As Kasemir correctly pointed out, most clients don't need all the details the low-level clients can provide. With that in mind, I created a parser, protocol aware, that always returns the same NT-ish data structure. Parts of it were also based on PVWS, but tailored for WEISS' needs. On the connection management layer, epicsWS, I just call the proper parser method according to the PV provider from which the update came from. I have used this approach for a while now, and can switch seamlessly between CA and PVA. 

FWIW, although those were developed specifically for WEISS backend, the application can be used as a standalone service via the docker container or local build. 

Hope this helps!

Cheers,

André Favoto

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, June 8, 2026 19:25
To: Marks, Nicholas <nmarks at anl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: CA Provider for PVXS

 

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.