Handling of PVAccess meta fields

[jacomago]

Discussing with @mdavidsaver I found out a few things about the pva protocol.

At the moment I handle the field value in EPICS_V4_PV by trying to map to the CA behaviour. However I'm thinking we could do something different considering we have the only receiver updates on changes part of the protocol.

Currently we try to track the diff from the current to the previous structure, and map to the ca field names.

• Since we get the bitset, we could just ignore the metafields part of the policy file for pvAccess and store every update the the subfields.
• Or, the protocol supports subscribing in a more complicated way to only the fields that you are interested in, and again we just store every up date.

I think the storing everything every day is a good feature to keep, but we should make it configurable and set a default of the STS periodicity (so for instance we should have the full metadata every pb file.)

One thing is that we don't store when the timestamp doesn't change, I think its reasonable to keep this behavior. But it does mean if for instance an alarm is set we would lose this.

[mdavidsaver]

I think the storing everything every day is a good feature to keep

If AA will store deltas, then full blobs (aka. key frames) need to be stored occasionally. Once per day (or once per file) seems reasonable to me. Still, I wonder if it would be better to use update count instead of time. eg. every 128th update. I would naively think that this would bound retrieval time regardless of effective update rate, and might be simpler to implement.

[mdavidsaver]

One thing is that we don't store when the timestamp doesn't change, I think its reasonable to keep this behavior. But it does mean if for instance an alarm is set we would lose this.

I agree. It is usual for record processing to update TIME even when SEVR changes while VAL remains the same. I brought this possibility up because at the time epics-base/epics-base#803 would have updated SEVR without updating TIME. This PR has since changed.

I recall that is the same situation causes problems with eg. the non-VAL fields of motorRecord.

[jacomago]

If AA will store deltas, then full blobs (aka. key frames) need to be stored occasionally. Once per day (or once per file) seems reasonable to me. Still, I wonder if it would be better to use update count instead of time. eg. every 128th update. I would naively think that this would bound retrieval time regardless of effective update rate, and might be simpler to implement.

Update count might be better. I was thinking of every partition granularity and then you could write it into the file header. But could possibly do some kind of combination.