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:
- You want to serve data, so you fill the data container
- You read data, so you get the container.
OK, in the first step of the read protocol you get the description of the data, but then in the next step you need to fill that with data, so you do create the container right away.
- You monitor data, so you apply received changes from a 'small' container to the 'full' container that caches the complete structure.
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
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
|