On 07/18/2018 01:20 PM, Siniša Veseli wrote:
Hi,
I realize I have not been attending the working group meetings lately, so I apologize in advance if I missed something.
Reading through some of the github issues that seem to be getting a lot of attention recently, it seems like we are getting a completely new set of PVA client/server C++ APIs, which raises several questions in my mind:
1) Are those APIs becoming the "official" EPICS PVA client/server APIs? In other words, if I am starting a new C++ project based on EPICS7, should I start with the new interfaces, or work with the ones available in the most recent 7.0.1.1 release?
My new client API (pva/client.h) is actually in the 7.0.1.1 release. I wrote this last summer. It is the result of my
experiences using the ChannelProvider API with the PVA gateway prototype, the P4P client,
the CLI tools, and in unittest code for QSRV and the PVA gateway.
pva/client.h is my attempt to distill out the code common to all of these use cases.
Since 7.0.1.1 I've successfully used it in the new PVA link support, some of the CLI tools, and recently
rewritten the P4P client around it. In doing this I didn't have to make any incompatible changes, just to
add a few missing pieces and make bug fixes. So from this point I expect it will remain stable. I plan to
apply it to the PVA gateway the next time I iterate.
As for the (very new) server API. This does not attempt to be fully general purpose, eg. it won't be
enough to build a gateway. Instead, it is a direct decedent of the server code common to QSRV and the unittests
of the PVA gateway prototype, which is will replace. This common code is what has held these two otherwise
unrelated projects in the same source repository.
So far it's only been use behind the P4P server API. I'll consider it stable once it has been successfully
used a few more times (by myself, or others). So I suppose you could call it a "technology preview" in the
upcoming 7.0.2 release (a step I think should be mandatory for all new APIs).
As for "official"-ness; these APIs will be released, and I will continue to use them in my own projects,
and as a tool to test the underlying PVA client and server code (hopefully finding bugs before you do).
Should you use them?
I'd like to get feedback from people like yourself who also have experience with both the low-level
ChannelProvider API, as well as Marty's pvaClientCPP/pvDatabaseCPP. My goals are that these new APIs should be easier to use,
harder to break, and perform just as well. If I'm not meeting these goals, then I'll do something about it.
2) If #1 is true, what becomes of the current pvaClientCPP and pvDatabaseCPP APIs? Will those be deprecated? Or are we going to have two separate sets of high-level C++ APIs?
As you allude to in #3, Marty and I disagree about pvaClientCPP and pvDatabaseCPP, of which I am not a fan.
I don't know what his plans are, but I have not, and will not, dissuade him from continuing to develop these modules.
So yes, it looks like there will be two sets.
3) It looks like there are some rather significant differences in behavior between the new and existing interfaces. Have those differences been summarized anywhere?
No. I can only refer you to my documentation. See "Client API" and "Server API", and particularly the "API usage Examples".
http://epics-base.github.io/pvAccessCPP/
I would imagine that making API changes like this, and for a project that numerous sites depend on, requires some sort of process: somebody comes up with a proposal and plan, there is a discussion about advantages/disadvantages and about the consequences for the existing code and for the future development, and (most importantly) there is an agreement between the developers as far as the direction that project will be taking. If this was discussed in one of the v4 meetings already, sorry that I missed it, and I would appreciate if someone points me to the document where all of this has been written down.
My motivation for this tool smithing is that I found the existing options quite awkward, error prone,
and unlikely to change. I know that others have similar experiences. I developed some patterns and
utilities to cope with this. I also dislike copy+pasting code between projects. These new APIs are
the end result of this process. I know they are useful to me. I think they will be useful for others,
but only time will tell.
On a personal note, few years back, after we all decided that the new client API (pvaClientCPP) will be implemented, I had to put in a fair amount of work to replace my own high-level API with the official one, and I would not be exactly looking forward to yet another iteration of the same. However, if this was already discussed and agreed upon, then so be it.
If you're happy with pvaClientCPP, then I see no immediate reason for you to change. The low level
ChannelProvider API on which all of these high level APIs are based will be maintained (warts and all)
for the foreseeable future.
Eventually, I hope that you will conclude that these new APIs would make your job easier. But only you
can be the judge of this.
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·