|
From: Marty K. <mrk...@co...> - 2010-09-07 19:08:51
|
On 09/07/2010 11:15 AM, Carcassi, Gabriele wrote: > Hi Marty, > > 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. >> Thus pvManager present all data via a single interface. But instead of >> proving 3456 interfaces it provides just 8 interfaces. It does this by >> limiting choices are follows: >> >> The value data types supported are int32, float64, string, and enum. > I got this from both Kay and Bob independently: while there is a > difference on the wire, the client is not going to care that much about > the difference among different integers or floats. > May be true for scalars. But for megaByte arrays there is a big different between an int8 and an int64. Also you use an int32. Thus you do not support int64. >> For each a scalar or array is supported. >> For each data type all of alarm, timeStamp, and display are included. > Again, this was decided during the discussion, to keep things simple. > Right now we are shooting for getting everything, but we can always > scale back if we find problems. > This is my BIG concern. In fact it is the whole point of my message. See next. >> I believe that it will be very hard to provide an efficient >> implementations for either V3 CA or for pvAccess. > Why? Because we are limiting the options to get everything or nothing? > > Again, don't confuse the pvManager client interfaces with what goes on > the wire: these are two different things. The fact that the data type > defines all the elements does not mean that they always have to be > present and returned. You can still return null or throw an > UnsupportedOperationException. They are methods: they can do whatever we > need them to do. > 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. This is not very nice, not very efficient, and really a mess. Marty |
