Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Sat, 12 Jan 2019 17:05:18 -0800

Forgive me for the slow reply.  I wanted to focusing on new work
before returning to belabor this dead horse.

The work being a new access control API which should make it
possible to bring write restrictions, and caputlog, to QSRV.

https://github.com/epics-base/pvAccessCPP/pull/136

On 1/10/19 6:22 AM, Kasemir, Kay via Core-talk wrote:
> Hi:
> 
> Is it possible that qsrv doesn't fully use the request information?

QSRV ignores the field mask part of the request, and will continue to do so
until I get time to rewrite it to use my high-level server API (SharedPV).

https://github.com/epics-base/pva2pva/issues/11

From that point it will make use of the field mask, though in a different
way to Marty's pvDatabase.  These differences are summarized here:

https://github.com/epics-base/pvDataCPP/pull/56

> It may not be an operational issue,

One of the selling points of pvData was the idea that extra fields could be
added without breaking clients.  However, this break down if any particular
layer is allowed to assume the it will see only those fields it expects.

Lest you think this is theoretical.  This past summer I found that the GDA
client from DLS is doing exactly this.  This discovery is what prompted me
to write PVRequestMapper (see epics-base/pvDataCPP#56 link above)

Here we have findSetter() which takes an arbitrary Java object and a pvData field name.
It attempts to find (by case insensitive match no less) a method named "set<fieldname>".
The ignoreUnknownFields option is naturally hard coded to false.

https://github.com/DiamondLightSource/pv-marshaller/blob/f08beb373407d4b4bcac710849699741c46c09cd/pvMarshaller/src/org/epics/pvmarshaller/marshaller/deserialisers/Deserialiser.java#L133-L157

The actual iteration of the PVStructure happens in createObjectFromPVStructure().
There are a couple of layers between, but I hope this shows the same of things.

https://github.com/DiamondLightSource/pv-marshaller/blob/f08beb373407d4b4bcac710849699741c46c09cd/pvMarshaller/src/org/epics/pvmarshaller/marshaller/deserialisers/StructureDeserialiser.java#L48-L115

The upshot of this is that imo. allowing users of QSRV to begin depending on this
behavior, and write client code like that, would limit my options for future
compatible extensions to QSRV without good reason.

...
> It may not be an operational issue, because you typically want to get the complete NT* type for records served via qsrv.
> But it's inconsistent, and it's unfortunate for training sessions where pvaSrv allowed me to say:
> Look, you can read records via PVA and easily get just the units as  pva://record/display/units, because PVA generally allows you to fetch just what you want.

This will work in either case.  QSRV strictly gives more than is asked for.
So 'display.units' will be available if it exists.

> I think pvDatabaseCPP automatically supports requests for subsections of a structure.
> Is qsrv not using pvDatabaseCPP for performance reasons?

There are other, perhaps more subjective reasons from my not using pvDatabase.
But I hope you'll understand if I don't want to dig up that diirt right now.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System