RE: [Pvmanager-devel] user data interface: Single complex interface vsmultiple simple interfaces

[Carcassi, G. <car...@bn...>]

>> Didn't we already have this discussion when we were all here?
>>
>Yes and I never got anyone to understand my concern. I am trying again.

Ok, I thought we came to a good understanding at the end... my bad...

>May be true for scalars. But for megaByte arrays there is a big 
>different between an int8 and an int64.
Yep: arrays we will have as many as we need. In java means byte, short,
int, long (8/16/32/64) plus float and double (32/64).

>Consider caV3. Does this mean that the implementation always ask for 
>DBR_CTRL_XXX. Lets assume DOUBLE. This is really expensive. Or does the

>implementation issue DBR_DOUBLE and then the first time the client asks

>for something from alarm cancel the DBR_DOUBLE and ask for a 
>DBR_STS_STRING, and so on and so on.
Right now, we are assuming to have the whole thing, because most of the
time that's what we are going to use for display. So:
PVManager.read(vDouble("epics3://mypv")).atHz(10);
would give you everything.

A way to scale back is:
PVManager.read(vDouble("epics3://mypv?alarm+time")).atHz(10);
which gives you the alarm and time but no display information. You still
get a VDouble, with all the methods, but for the things you didn't
request you would either get null or an UnsupportedOperationException
(depending on what we think it's better, which I am not sure either).

The current position is that you get what you asked at connection time.
You can't "upgrade": you have to re-ask. All pieces needed are known
before connection time (except things like size of the array).

Gabriele