|
From: Benjamin F. <ben...@be...> - 2010-09-07 11:32:44
|
Hi Marty
you said you'd create a new thread but you did not, you merely changed the
subject line. Thus I am creating a new thread, now. I hope people take the
hint and reply to this message and not to your original one.
---------- Forwarded Message ----------
The following makes the case that providing data via multiple simple
interfaces is better than a single complex interface. As an example
instead of an interface DoubleTimeStampAlarmDisplay it is better to
present the user with separate interfaces Double, TimeStamp, Alarm, Display.
This message only discusses pvManager data which consists of some
combination of value, timeStamp, alarm. and Display.
Consider the number of options for each:
value
Potential types to support consist of
primitives: boolean, int8, int16, int 32, float32, float64
string: This is treated like a primitive.
enum: This is composite but for this discussion let it also be
considered a primitive.
For all types except enum both a scalar and an array is supported. At
the present time neither CA V3 or pvAccess allows arrays of enums so the
discussion assumes that an enum can only be scalar.
There should also be a choice of no value.
For a connection a client can choose only one type. So there are 8*2 +1
+ 1 = 18 choices.
timeStamp
This is secondsSinceEpoch and nanoSeconds. Thus there are 2 components.
alarm
The definition of alarm is still under discussion so for this
discussion just assume it is severity, message, and deviceStatus.
deviceStatus is a composite but again for this discussion it is treated
like a single thing. The severity is treated as an int with an
associated enum interface and can this also be treated as a primitive.
With these assumptions an alarm has three components.
display
This consists of:
units, format
displayLow, displayHigh,
controlLow, controlHigh,
alarmMajorLowValue, alarmMajorHighValue, alarmMinorLowValue,
alarmMinorHighValue
Except for units, format, and the alarmSeverities the type could be any
of the numeric primitive types. Rather than considering this
complication just assume they are always float64. It will not
drastically change the following arguments. With this assumption display
has 10 components.
The above is what is to be made available to a client. How is the
question. The following considers two possibilities. The first allows
one value choice and for each of timeStamp, alarm, and display allow any
combination. The second picks a set of choices for each of timeStamp,
alarm, and display. The set of choices is based on how the data is
expected to be used by clients. For each possibility the total number
of interfaces is determined assuming: A) everything is presented in a
single interface, and B) separate interfaces are used for value,
timeStamp, alarm, and display.
First Possibility: one value choice and all possible combinations of
timeStamp, alarm, and display.
There are: 18 choices for value, 2 components for timeStamp, 3
components for alarm, and 10 components for display.
A: Present all data via single interfaace.
For value there are 18 choices. For each of the others there are
2**ncomponents, choices.
Thus number interfaces = 18*(2**2)*(2**3)*(2**10) = 589824 interfaces
B: Present data with separate interfaces for value, timeStamp, alarm,
and display
Now there are 18 + (2**2) + (2**3) + (2**10) = 1054.
Thus for this possibility B is really bad and A is absolutely horrible.
Thus lets limit the choices for each of timeStamp, alarm, and display.
The following attempts to choose useful subsets. It is not meant to be
the definitive subsets. Another choice changes the details but not the
conclusion.
timeStamp
For this just allow: 1) no timeStamp or 2) full timeStamp. Thus 2 choices.
alarm
Break this into two separate things: 1) alarm, which consists of
severity and message, and 2) deviceStatus. For alarm three choices will
be allowed: 1) no alarm,
2) severity only, and 3) severity and message. For deviceStatus there
are two choices: 1) no deviceStatus and 2) full deviceStatus.
display
allow any combination of unitsFormat, displayLimits, controlLimits, and
alarmLimits. Mapping of complete set of display fields to these should
be obvious.
Thus there are 2**4 = 16 choices.
A) Present all data via single interface
Number interfaces = 18*2*3*2*16 = 3456.
B) Present all data via separate interfaces:
Number interfaces = 18 + 2 + 3 + 2 + 16 = 41 interfaces.
I claim that B) is quite manageable. A) is horrible.
So what does the current definition of pvManager provide since providing
3456 interfaces is not really feasible.
NOTE: pvmanager is a lot more than data but I am only discussing the
data interfaces that must be implemented by some data source like V3 CA
or pvAccess.
I may not be looking correctly but I think the following is the complete
set of data interfaces that are presented to clients and must be
implemented by the data source. I suspect that the rest of the VXXX
interfaces can be or are already implemented by pvManager itself.
VDouble, VDoubleArray, VEnum,VEnumArray,VInt,VIntArray,VStriing,VStringArray
All are somewhat similar except for the value data type so let's
consider just one.
public interface VDouble extends Scalar<Double>, Alarm, Time,
Display<Double> {}
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.
For each a scalar or array is supported.
For each data type all of alarm, timeStamp, and display are included.
I believe that it will be very hard to provide an efficient
implementations for either V3 CA or for pvAccess.
Marty
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
-------------------------------------------------------
|