Re: PV Access Protocol Specification

[Timo Korhonen via Core-talk <core-talk@aps.anl.gov>]

Hi Kay (and others),

I am afraid that this is the latest version of the document. The community has accumulated a lot of documentation debt. ESS is eager to support a documentathon, we are just waiting instructions on when the community would like that to happen.

By the way, reading the F2F core meeting notes, there was a mention about rescuing the documents from the old V4 site (epics-pvdata) and putting them on the new website. Nobody seems to have looked at the new website, under "Resources and Support" -> "Documents"; if you look carefully, there is an item called "pvAccess". Under that item you find links to a number of documents and even a downloadable "pvAccess Protocol Specification" pdf. I have also a similarly formatted Normative Types document but I was discouraged from making pdf documents so it has not been put there.
Or, of course, because the website structure is "wrong", nothing can be found. The structure was modelled after the APS website and reviewed by the community. Just saying. Let us do it right, then.

Rescuing the items from the V4 site could be completed at the documentathon. Or by the numerous volunteers that will jump up to help in creating content for the new website. Next time we will give t-shirts only to people who have contributed.

Timo, the grumpy old man.


On 10/04/19 14:30, "core-talk-bounces@aps.anl.gov on behalf of Kasemir, Kay via Core-talk" <core-talk-bounces@aps.anl.gov on behalf of core-talk@aps.anl.gov> wrote:

    Hi:
    
    Google pointed me to http://epics-pvdata.sourceforge.net/pvAccess_Protocol_Specification.html, "Fourth (in progress) Public Working Draft, 16-October-2015", "<to be> followed by publication of the specification."
    
    It has a lot of information, but the very first specific information about size encoding is already wrong:
    """
    If the number of elements is less than 255, the size MUST be encoded as a single byte containing an unsigned 8-bit integer indicating the number of elements
    If the number of elements is less than 2^31-1, then the size MUST be encoded as an unsigned 8-bit integer with value 255, followed by a positive signed 32-bit integer indicating the number of elements
    If the number of elements is greater than or equal to 2^31-1, then the size MUST be encoded as an unsigned 8-bit integer with value 255, followed by a positive signed 32-bit integer with value 2^31-1, followed by a positive signed 64-bit integer indicating the number of elements. This implies a maximum size of 2^63-1.
    """
    
    The current implementations (https://github.com/epics-base/pvDataCPP/blob/master/src/misc/serializeHelper.cpp#L34, https://github.com/epics-base/epicsCoreJava/blob/master/pvDataJava/src/org/epics/pvdata/misc/SerializeHelper.java#L35) use 254 instead of 255 as the "larger size follows" marker, 255 is used to encode 'null', and values beyond 0x7fffffff=2^31-1 are not implemented.
    
    Is there a current PVA protocol specification?
    
    Thanks,
    Kay