Re: 'Request' support in qsrv

[Mark Rivers via Core-talk <core-talk@aps.anl.gov>]

Yes, my example is still hypothetical.  It does closely mirror how the areaDetector ImageJ plugin for Channel Access works.  It does the following:

- Puts a monitor on the ArrayCounter PV.  This means it gets a callback each time there is a new array.

- Reads the metadata to decide how much data it needs to read from the waveform record.  This may be much less than the actual size of the waveform record.

- Based on the metadata reads the actual data from the waveform record.


It does this, rather than monitoring the waveform record directly, because if it did the latter it would need to be reading the metadata and changing the requested size of the monitor callback each time anything changed.


This is not needed with pvAccess, in that case ImageJ is directly monitoring the entire NTNDArray structure.


Mark



________________________________
From: Michael Davidsaver <mdavidsaver@gmail.com>
Sent: Monday, January 14, 2019 11:39 AM
To: Mark Rivers; Ralph Lange
Subject: Re: 'Request' support in qsrv

On 1/14/19 9:18 AM, Mark Rivers wrote:
> I don't know of any current examples, but I could imagine a client wanting to know if an image was RGB or Mono for example, if that client could only handle Mono.

Ha :)  I complain about hypothetical use cases, and I get?  Another hypothetical use case!


In seriousness though.  The problem with this example is that it is effectively polling.
This inherently add round trips, failure modes, and extra code to address them.  eg.
You can poll Mono vs. RGB and then start consuming, but a robust client must consider
that the color mode can change without warning.

To me, this sort of situation often only becomes apparent when I actually start writing code.
Thus my growing aversion to discussing use cases which none of the participants have tried
to solve.


> ________________________________
> From: core-talk-bounces@aps.anl.gov <core-talk-bounces@aps.anl.gov> on behalf of Michael Davidsaver via Core-talk <core-talk@aps.anl.gov>
> Sent: Monday, January 14, 2019 11:13 AM
> To: Ralph Lange
> Cc: EPICS Core Talk
> Subject: Re: 'Request' support in qsrv
>
> On 1/14/19 8:30 AM, Ralph Lange via Core-talk wrote:
>> On Mon, 14 Jan 2019 at 17:17, Kasemir, Kay via Core-talk <core-talk@aps.anl.gov <mailto:core-talk@aps.anl.gov>> wrote:
>>
>>
>>     [...]
>>     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.
>
> This seems hypothetical.  Has anyone ever wanted to do this?  What was the motivation?
>