V4 2nd Design Meeting Notes

2nd Design Meeting (APS) - Notes

Who is the customer?

As there are no big machines coming up and lots of existing installations, V4 will be targeting the whole community.

Compatibility and conversion issues

V4 will not support 68k processors under Tornado2, only under RTEMS. (There might be memory footprint issues, though.)

Lower limit: 8MB/68k or 16MB/coldfire - i.e. must support small and embedded systems.

Gateways will be used to convert CA connections between V3 and V4 within one system.

We should provide a set of asara records (asara = as similar as reasonably achievable) providing V3 behaviour that can be used for automatic conversion of existing V3 databases.

DBD syntax and generation

Building blocks

It seems wrong to have real C++ declarations within the dbd file. The interface definitions should rather reside in a separate header file. (That way it would be easier to e.g. have the interfaces in different languages.)

Declarations of fields and views

The V3 prompt declaration will be replaced by a "hint" or "help" text that can be applied to any entity defined in the dbd language (not just fields). Tools may use that text to display bubble help or similar things.

The V3 group declaration will be replaced by views that can be used by the configuration tool to group things into hierarchies.

Hierarchies

Jeff envisions a "global" hierarchical namespace, where a request for quad4.ps2.current.analogValue.val would be answered by a "virtual" record that forwards and collects things from different records. Such a virtual could reside on a different node. (I would call it part of middleware functionality.) It is unclear who would be writing such a record.

Agreement on: Everything before the first dot is a record name.

V3 compatibility records will define views like

view (HIHI) {
    property (....)
}

so that clients can still use the old syntax of <recordName>.<fieldName> to access fields.

Programmatic views will accept arguments (in parantheses). I.e. the programmatic "field" view will take the field name as an argument, as in

xxx.field(displayLimit)

Subproperties will be addressed using multiple dots, as in

xxx.value.displayLimits.upper

(This might map to a numeric property address - using an array of propertyIds - when transferred over CA.)

Clients should be able to find out if a certain property implements "analog", "enumerated", or "string" behaviour. (To make handling unknown properties easier .) Making the IOC answer these kind of questions induces a number of problems (versioning etc.) It might be possible to implement these "types" of properties as a conveniency layer library on the client side.

Record instance syntax

i18n

LOCALE techniques will be supported on systems that support it, on a level as close to the user as possible. (We're trying not to preclude someone from using LOCALE.) I.e. the dbd file (being a kind of source file) will need the "." character as a decimal point. It is the task of tools (like vdct) to convert any data in LOCALE format (e.g. using "," as decimal point character) to the standard format in the dbd file.

Data Access

Type info

The presented first version of a third set of traverse and find methods to find out the native types of properties does not seem to be efficient and desirable.

CA/DA Convenience layer / user interface

There will be a higher level interface library on top of Channel Access and Data Access that hides the inherent complexity and provides the end user with a simplified way to get to the structures, type, and data.

Collecting the requirements and defining the interfaces of that convenience layer is a task with high importance and priority. (Doug and Kay did a first step in that direction.)