Hi,
Judging from Michael's comments, documentation, epics meeting slides,
etc. it looks like these new APIs are indeed meant to replace what we
had since v4.5 or so. While I am not necessarily opposed to such change,
I do have a few points I'd like to make:
1) EPICS in itself is probably not the easiest software to learn and
use. Having two sets of C++ APIs does not help and can be terribly
confusing. If I were new to Argonne, and someone told me to write an
EPICS C++ client for the first time, and then I were to discover that in
epics base we have client.h and pvaClient.h that seem to be completely
different, that we have two sets of examples, different documentation,
and in some case different behavior between the clients, I would ask
myself "What is going on here, and who the heck designed all of this...".
2) Maintaining and supporting two sets of high-level APIs is not
feasible in the long run. Resources that we have for epics development
are scarce, and those should be used wisely. This is something that
anyone sitting on the council should be concerned with. Why would we
have Marty or anyone else spend lots of his time on pvaClient and
pvDatabase if we are going to get rid of it in 6 months or in a year? I
would personally rather spend my time on something that will have a
lasting impact on the project, rather than fixing a bug or two in
something that is viewed as temporary.
3) I would hope that EPICS development project has some sort of coherent
strategy in terms of what gets developed and why, what are the
recommended user interfaces, etc. Module owners have a wide latitude and
control in terms of how they want things to be done. However, in a case
where someone feels that a new high-level C++ API is needed because the
old one is just not good, or if they wanted to make API changes that
affect users or other downstream modules, I imagine there would be some
group discussions and planning around that, so that we all know what is
going on. We may not all agree about particular set of changes, but at
least everyone would get their say and the group would build some sort
of consensus around the direction that the project is taking.
It seems like there was not much discussion in this particular case. New
interfaces appeared in the base code at some point, and are finding
their way slowly through the rest of the system, so now we have two sets
of APIs, and that's just how it is... Depending on who you talk to
first, you might go this way or the other for developing your own code,
and hope that the path you've chosen will not be deprecated in the next
release. This just does not seem to be a good thing as far as EPICS
users are concerned.
I am not arguing to maintain some sort of status quo here, but I am not
sure I completely agree with how are changes being introduced at the
moment. If new client/server APIs are going to be significantly better,
if we need to change the way we use PV requests in our code, etc., that
would all be fine with me, as long as this was discussed, consequences
were understood, transition plan for the old code was developed, etc.
This email is not meant to offend anyone, if I did so, then I am sorry
and I apologize in advance.
I do appreciate Michael's clarifications on what happened and how things
are at the moment.
Sinisa
On 7/19/18 1:42 PM, Marty Kraimer wrote:
On 07/18/2018 08:05 PM, Michael Davidsaver wrote:
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.
Michael is creating a new client API for pvAccess.
https://github.com/epics-base/pvAccessCPP/blob/master/src/client/pva/client.h
He has used this API as the basis for
1) pvTools. In particular pvget and pvput
2) pva2pva. Both qsrv and gateway
3) p4p
The issues
https://github.com/epics-base/pvAccessCPP/issues/116
and
https://github.com/epics-base/pva2pva/issues/21
Show that pvTools and qsrv have broken the exceptions of existing
clients and servers.
In order to support both the existing clients and Michael's new client
API then there will have to be two implementation of at least pvTools
and qsrv. If we continue with two client API's there will probably be
a need for more dual implementations.
Marty
--
Siniša Veseli
Scientific Software Engineering & Data Management
Advanced Photon Source
Argonne National Laboratory
[email protected]
(630)252-9182
- Replies:
- Re: C++ APIs Michael Davidsaver
- References:
- C++ APIs Siniša Veseli
- Re: C++ APIs Michael Davidsaver
- Re: C++ APIs Marty Kraimer
- Navigate by Date:
- Prev:
Re: C++ APIs Marty Kraimer
- Next:
Re: C++ APIs Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: C++ APIs Marty Kraimer
- Next:
Re: C++ APIs Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|