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.
- Replies:
- Re: 'Request' support in qsrv Kasemir, Kay via Core-talk
- References:
- 'Request' support in qsrv Kasemir, Kay via Core-talk
- Navigate by Date:
- Prev:
Re: Int64 PV and caget Williams Jr., Ernest L. via Core-talk
- Next:
Re: Int64 PV and caget Ralph Lange via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: 'Request' support in qsrv Marty Kraimer via Core-talk
- Next:
Re: 'Request' support in qsrv Kasemir, Kay via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|