Experimental Physics and Industrial Control System
Hi:
Marty, Michael, thanks for the updates.
So https://github.com/epics-base/pva2pva/issues/11 already confirms that QSRV always serves the complete structure, and it'll be fixed when ".. changing QSRV to use SharedPV".
Good that you thought about the case where clients request some optional fields that may not exist.
> 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.
Of course each layer needs to be somewhat tolerant.
Check if there is a "timeStamp", then get the "secondsPastEpoch" and "nanoseconds".
These two must exist, otherwise it's not a normative timestamp.
But if a server decides to add another field to the timeStamp, that needs to be tolerated by all clients.
Still, if I specifically request a field, it's problematic to send the complete structure.
The SNS neutron data clients request specific fields to reduce network load.
Sending the complete structure to all clients would overload the network.
For records and QSRV I don't see that as a practical issue because even though you get the complete structure, only changes require network bandwidth.
The only problematic scenario would be a large waveform record where some client solely requests the timestamp.
Always adding the complete waveform would increase the network traffic compared to just the requested timestamp, but I think that's a silly example.
In any case, sounds like you plan to update QSRV eventually, so then it's all perfect.
Thanks,
Kay
- Replies:
- Re: 'Request' support in qsrv Ralph Lange via Core-talk
- References:
- 'Request' support in qsrv Kasemir, Kay via Core-talk
- Re: 'Request' support in qsrv Michael Davidsaver via Core-talk
- Navigate by Date:
- Prev:
Re: Int64 PV and caget Williams Jr., Ernest L. via Core-talk
- Next:
Re: 'Request' support in qsrv 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 Michael Davidsaver via Core-talk
- Next:
Re: 'Request' support in qsrv 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