Experimental Physics and Industrial Control System
>>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.
>Make that a client that only wants to check the metadata of a huge image (e.g. to decide on the image size if it wants to read the image data itself), and it's not silly anymore.
For images sent from AreaDetector's PV plugin, all is fine.
This will only fetch the dimension[], no image data:
pvget -vv -r dimension 13SIM1:Pva1:Image
Only QSRV sends the complete struct, and there's a plan to fix that.
We may not know by when, but it's no show stopper.
Priority wise, replacing the display.format string with display.precision and display.what_to_call_it would be more important.
How about a google form?
https://docs.google.com/forms/d/e/1FAIpQLSeYNwsym8av05h2yqjUfw5kcluv37kZ5-dVPGjaZuSI7YtaWQ/viewform?usp=sf_link
Thanks,
Kay
- Replies:
- RE: 'Request' support in qsrv tom.cobb--- via Core-talk
- References:
- 'Request' support in qsrv Kasemir, Kay via Core-talk
- Re: 'Request' support in qsrv Michael Davidsaver via Core-talk
- Re: 'Request' support in qsrv Kasemir, Kay via Core-talk
- Re: 'Request' support in qsrv Ralph Lange via Core-talk
- Navigate by Date:
- Prev:
Re: 'Request' support in qsrv Ralph Lange via Core-talk
- Next:
Re: 'Request' support in qsrv Michael Davidsaver 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 Ralph Lange via Core-talk
- Next:
RE: 'Request' support in qsrv tom.cobb--- 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