Marty Kraimer wrote:
I suspect, however, that specifying how type_info is defined will
lead to lots of debate starting with the definition of primitive
types and then strings and arrays and then structured data.
Benjamin and I didn't want to lose discussion time and decided to go
ahead starting that debate ....
Our idea is to /not/ make that type info a simple fixed enumeration of
fixed types, but use a dynamic structure to describe a type. We came
up with the following:
type = string 1)
| timestamp 2)
| signed (bitwidth) 3)
| unsigned (bitwidth) 3)
| float (float_format)
| struct 4)
| array (base_type, size) 5)
float_format = ieee32 | ieee64 | ieee80
Annotations:
1) String should be a basic atomic type - regardless of its
implementation.
2) For efficiency reasons (as timestamps are shipped around and
handled all the time) the timestamp should be an atomic type that can
easily be mapped and assigned to the EPICS supported C/C++ types.
3) A server or client app can choose any locally available data type
that is appropriate and wide enough to store the data. Future wider
integers are supported. As for signedness, alternatively there could
be one integer type with another parameter giving the integer format:
| integer (int_format, bitwidth)
with
int_format = unsigned |signed
4) This basic type is needed for properties that actually are a
contained list of other properties.
5) base_type is another type_info. If we need a type where arrays do
not start with element zero, size might be replaced by a (min, max)
pair. Multi-dimensional arrays are represented as arrays of arrays.
This type_info has a dynamic size (it's a union - which really seems
to be a natural way to describe lots of things...). Making itself a
property catalog seems a slim and convenient way to interface it.
IOC side ideas:
It is perfectly allright for the IOC Database implementation to use a
fixed enumerated number of fixed types. This may be the most efficient
implementation. When the CA connection is made, the CA server will
have to find out about the types of a property catalog owned by a
record using the type_info to decide which network representation it
uses for the data.
In case of a fixed list of enumerated fixed types, a bunch of static
property catalogs will be enough to fulfill most of these type_info
requests. A plain table can hold the connections between fixed types
and their type_infos. (There's no need to generate a type_info
property catalog for each record instance nor for each record type.)
For menus, the needed bitwidth could be reported correctly to the CA
server, as the number of choices is fixed at compile time. This would
allow CA and the client side to optimize storage - independent from
the implementation in the IOC Database.
Possible DBD look-and-feel:
Wouldn't have to change. If the Database is implemented using
predefined fixed types, everything stays the same. Otherwise, the
parametrized types would be used instead of the fixed ones, i.e.
int32 would become signed(32)
float64 would become float(ieee64)
and so on.
So much for the first iteration....
Benjamin and Ralph
