RE: CAS server and partial vectors

[Bruno Coudoin <bruno.coudoin@gmail.com>]

Le vendredi 17 avril 2009 à 18:47 -0600, Jeff Hill a écrit :
> Hello Bruno,
> 
> Currently, it works like this.
> 
> - the client can ask for no more than the number of elements provided by the
> service when the channel connects to the PV.

Ok but how does it knows how many elements to ask for. As I see it, only
the server can know the current number of element in its gdd.

> - the client always gets the number of elements he requests,

This is ok for me but in my case I will always ask for the max number of
elements. If I don't do this I would just loose data.

>  and should the
> service provides less, then the server zero pads in the protocol.

Ok, that's what i saw.

> I will admit that one could make a good case for this not being terribly
> flexible, but this was a behavior adopted a long time ago and we are careful
> to preserve backwards compatibility.

I understand but there is probably a way to fix it and keep backward
compatibility. One can assume that if nobody complains about this is
because no one use epics to send partial vectors.

Thinking about it the risky part would be to have a new server sending
partial data and a old client expecting a zero padded payload.

By the way I don't know the epics ecosystem enough to make a proposal.

> One solution might be to make the first element specify the number of
> elements that follow. That would, admittedly, not help with bandwidth
> consumption.

Yes, at least this would fix the functionality issue.