2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: pvData introduction |
From: | "Kasemir, Kay via Core-talk" <[email protected]> |
To: | EPICS Core Talk <[email protected]>, Timo Korhonen <[email protected]> |
Date: | Thu, 26 Sep 2019 13:04:17 +0000 |
Basically good.
I do worry about the 'introspection'. It's confusing, it's part of what makes the currend C++ API so hard, and most important it's hardly necessary.
PVData currently distinguishes between "Field" and "PVField", between the plain description of a structure and an actual container that holds data.
"type double" vs. "double 3.14".
The examples are full of two-step code that first creates the description, then the structure, with two copies of each, one using a "builder" and the other not using a "builder".
In reality, you almost always need the actual container:
The only example where you just need the description is the "pvinfo" command, where you never fill it with data.
With the new PVA java client and server, I've only implemented the container. The PVAxxx classes all hold data. When you read, i the first step you get the container where the double value = NaN, an array is empty, .., i.e. you get an empty container, but you
do get the container which is then filled with data one millisecond later.
OK, for the plain PVInfo command the container remains empty, the values are all 0, NaN, null, empty.
==> This has cut the amount of code in half, maybe even into just 25% because instead of
1) methods for field description,
2) builder for field description,
3) methods for data,
4) builder for data
I only have the builder for data, which in the pvinfo case is never populated with data
---> Much easier to understand, less code to maintain, works just fine.
So in the description, I would not talk too much about the not really necessary distinction between Field and PVField. That's just a side effect of the current implementation that makes it more confusing.
Thanks,
Kay
From: Core-talk <[email protected]> on behalf of Timo Korhonen via Core-talk <[email protected]>
Sent: Thursday, September 26, 2019 8:42 AM To: EPICS Core Talk <[email protected]> Subject: [EXTERNAL] pvData introduction Dear core developers,
I have to keep explaining PVA concepts to my colleagues over and over. To help myself in the task, I wrote a short piece of text where I tried to summarize the concepts of pvData. I picked up and edited pieces from different sources, mainly from the V4 website documents (Marty et al) and added some text of my own. Please take a look here: https://docs.epics-controls.org/en/latest/guides/OverviewOfpvData.html
It is not yet linked from the top menu that Ralph created in the Documentathon. Before doing that I would ask you to check: -if the text is factually correct or have I misunderstood something, -is it complete enough (i.e., have I missed something essential), -is the amount of detail appropriate; I intentionally reduced the amount of detail, to highlight the concepts in a concise way -any other suggestions and corrections (grammar, style) are also most welcome.
And also let me know if this has enough value to be added into the introductory documentation.
Timo
|