2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: C++ APIs |
From: | Marty Kraimer <[email protected]> |
To: | [email protected] |
Date: | Thu, 26 Jul 2018 10:38:35 -0400 |
On 07/22/2018 07:53 PM, Hartman, Steven M. wrote: Let’s have a teleconference meeting this week: Tuesday July 24 at the usual time (14:00 UTC).
The following is in preparation for the discussion. The primary conflict relates to the pvRequest structure that is an argument of the Channel create methods, i.e createChannelGet, createChannelPut, etc. The pvRequest structure is described in http://epics-pvdata.sourceforge.net/informative/developerGuide/developerGuide.htmlIn particular the sections 9. pvRequest and pvCopy 10. pvRequest Option For this discussion you can ignore the discussion of pvCopy. 9.2 describes CreateRequest which the client can use to create a pvRequest structure. The main features are:
One other important point. The client asks for the set of fields of interest to the client, e. g. "value,alarm,timeStamp". The server provides to the client only fields the client requests AND that the server supports. Also the server determines the type for each field it supports. Now for a little history. The Channel API was originally created as part of the JavaIOC project that started in 2006. For the first few years the only developers were Matej Sekoranja and me. I remember that we had discussion about how a client could pass options to the server. We went through a couple of iterations but each was not generic enough and would require changes to the network protocol. Then we realized that since we already had the ability to create complex data structures just have a argument that is a PVStructure. Thus the client can pass anything it wants to the server without changing the network protocol. But how do client and server agree of what is a valid request? The solution was CreateRequest and the PVStructure it creates. This was all in the JavaIOC by about 2008. In about 2010 BobDalesio said: This javaIOC is nice but what is required is a C++ implementation. Matej and I started on the C++ implementation with help mainly from Michael Davidsaver and David Hicken. So now we have both Java and C++ implementations of pvData, pvAccess, normativeTypes, pvaCliient, and pvDatabase. In addition a pvAccess server for accessing DBRecords was created. This was called pvaSrv. This became the responsibility of Ralph Lange. It used pvRequest as expected. A couple of years ago Matej no longer had time to work on pvData/pvAccess. Ownership of pvDataCPP and pvAccessCPP was assigned to Michael Davidsaver. In addition he was developing pva2pva, which was a combination of a gateway and a successor to pvaSrv. Michael decided, without any serious discussion with others that he did not like the pvRequest mechanism that was in place. So he often ignored it. qsrv is a particular problem. For example: mrk> pvget -p pva -r "value" DBRdouble There are other problems but qsrv is the really big one. |